login
v2
v1

jmoiron.net

Fluxbox & mouse wheel semantics

posted May5th, 2005 @ 23:55:23

- tags: development , general tech , linux

- comments: 0

For those of you possibly uninterested, this is going to almost entirely dwell on esoteric computer usability discussion.

Mouse wheel semantics are easier to talk about than other mouse behaviors. I attribute this to two things; they are mostly unencumbered by Apple usability studies, and there is intuitive spatial reasoning involved in them: the directions (up/down) tie into their action spatially on the screen intuitively rather than arbitrary like right/left buttons.

Recently, mostly as a result of features in windowmaker, scroll wheel behavior has started to be well defined for the window manager. Two features in particular are very useful : scrolling on desktop switches virtual desktop and scroll wheel on the titlebar rollsup/shades and rollsdown/unshades the window (for up and down directions, respectively). The first feature is prevalent in every major window manager except 1 (Metacity, mostly because the scrollwheel drops through to nautilus), and the second is slowly gaining acceptance (its configurable in kde's window manager and comes default in xfwm4).

I've recently switched down from Xfce4 to Fluxbox at work (mostly to reduce distractions), and found these two features either broken or missing. Fluxbox by default gives you 4 workspace, names them "one" through "four", and arranges them linearly from left to right starting with "one" (it doesn't show you this visibly, but "workspace warping", or dragging a window off the side of a workspace onto the next one, shows that this is implied). Scroll wheel up increases the number of the workspace (wrapping back to "one" at "four"), and scroll wheel down decreases this number; but this behavior feels clunky, unintuitive, and backwards.

The argument in favor of this behavior is that numerically it makes sense; up increases the number workspace you are on, and down decreases it. I believe that, regardless of this logic, this is semantically backwards when compared to the use of the scroll wheel in other situations.

Intuitively, the scroll wheel scrolls down in a scrolled window when you roll it down, and up when you roll it up. When you have overflow in a window, the established (and correct, for reasons I'll explain) behavior is to scroll NOT to the right, but in the direction of text in the current locale. If you have a utf8 operating system and set en_UTF8 as your locale, try going to an Arabic site with overflow and see the direction of horizontal scroll change!

This behavior makes sense because scrolling downwards follows the direction in which you read (all texts read downward as far as I know), and so scrolling downward on a horizontal bar should also scroll in the direction of text. Because of this, most people (people who read left to right) will intuitively think that scrolling down will go right, not left. When I asked around in #fluxbox on freenode, it seemed that many people change the direction themselves and then recompile it, but the fluxbox developers seem to be slow to include features in HEAD. For now, if you want to change it, go to line ~900 in src/fluxbox.cc and switch the "4" and "5" in the following lines:

} else if (screen->isDesktopWheeling() && be.button == 4 ) {
    screen->nextWorkspace(1);
} else if (screen->isDesktopWheeling() && be.button == 5) {
    screen->prevWorkspace(1);
}

Its an easy fix, but if a lot of users modify source to change default behavior, it might be time to change that default behavior, especially when evidence shows the changed behavior is more intuitive.

When I asked about the other feature on freenode, I was told that people disagree on what action scrollwheel on the titlebar should have: scroll among tabs (in fluxbox arbitrary windows can be grouped and tabbed), move that window to a different desktop, or rollup/rolldown. I think that as time goes on the established behavior will be rollup/rolldown, but its obvious by options given in other window managers that desired title bar behavior is varied. If you want this feature, I wrote a patch to be applied against the latest SVN version, and there are numerous patches for this behavior littered about the net.

comments