Wandering Thoughts archives

My mouse button bindings in fvwm, my window manager

I've previously described my X Windows window manager as highly customized. If you've looked at the picture of my desktop, this may sound a little bit overdone; sure, it looks different, but a lot of that is just running custom programs and a fair amount of the rest of it is ultimately chrome and not crucially important. As it happens, the visual appearance of my desktop is just the tip of the iceberg; most of my really hard to part with customizations are in mouse and keyboard bindings. Today I'm going to run down my commonly used unusual mouse bindings, as an example both of what I do and of what you can do in fvwm.

(I'm going to skip conventional mouse button bindings, the sort of thing that people find perfectly normal and predictable.)

To start with, I should note that mouse button bindings in fvwm can be different in different contexts, and also be made conditional on various modifier keys. This can lead to a huge and bewildering number of different mouse bindings, as you are about to see.

The left mouse button:

• with plain Alt, it raises the the window I'm over.
• with Shift+Alt, it iconifies the window I'm over.

The middle mouse button:

• with plain Alt, it moves the window I'm over.
• with Shift+Alt on the root window, it switches me back to the previous virtual screen I was on. Repeatedly clicking it will flip back and forth between two virtual screens.
• by itself on the root window, it brings up my main application menu.
• with Control on the root window, it brings up a menu of things I can do with the current X selection (such as use it as an URL or Google it).
• when I am placing a new window, it lets me resize the window as it's being placed.

The right mouse button:

• by itself on the root window or anywhere with Alt, it brings up my main menu (which has various window management operations, lets me start xterm, and cascades to all of my other menus). One of the things I use this for is conveniently resizing windows.
• with Control on the root window, it brings up a menu of 'root on host <X>' for commonly used hosts.
• when I'm placing a window, it immediately locates the window where the mouse is and extends it down to the bottom of the screen. This is a very convenient way to get tall terminal windows.

(In window titlebars (for windows that have them), the left mouse button raises and possibly moves the window, the middle mouse button moves the window, and the right button lowers it.)

Pretty much all of these bindings are completely ingrained and unconscious by now; generally I couldn't possibly tell you what the bindings actually are, even as I'm using them. I can write them down now only because I carefully read through my fvwm configuration file.

The functionality in these bindings may strike you as incomplete; for example, I can use a mouse button to raise a window but not to lower it. Part of this is because I also have keyboard bindings in addition to mouse bindings and for some things I generally work through the keyboard bindings instead. Part of this is just because I don't want to steal too many mouse bindings from programs.

A scroll wheel experiment

On the one hand, I am firmly a fan of three button mice where the middle button is a real button, not a scroll wheel. On the other hand, I'm becoming increasingly convinced that having a scroll wheel is useful (partly because my laptop has one as part of the trackpad). In order to reconcile these competing desires, I've decided to experiment with a hack.

(In an ideal world, the solution would be a three button mouse with a scroll wheel on the side, as I've wished for before. In this world, while such a thing may exist I haven't been able to find it, at least not for a moderate amount of money (cf).)

What I want is a scroll wheel. I don't have a bare one sitting around but we have plenty of standard USB scroll wheel optical mice, so I've taken one and plunked it down to the left of my keyboard (my usual mouse is on the right side). Since all I want is the scroll wheel, I've fixed the mouse so that it doesn't track (with the low tech approach of a piece of paper taped over the sensor on the bottom) and used xinput to turn off all of its regular buttons. This insures that I don't have to worry about any side effects of touching the mouse to use the scroll wheel.

(I briefly tried the USB mouse without these tweaks and found it annoying; I had to be careful not to shift the mouse and I was worrying about accidental mouse button clicks.)

I'm not sure that I'm going to use the scroll wheel regularly. There are obviously a number of annoying aspects to this setup, and I already know that I like things like middle button autoscroll in Firefox better than the scroll wheel. But that's why I call this an experiment.

(Some of my past interface experiments have been quite successful. Others, not so much. For instance, I still don't have a modern man page viewer that I like better than just running man in a terminal window.)

PS: one of the things that will make this work, if it does work, is All in One Gestures for Firefox, which makes it convenient to do a number of things via the mouse that usually require keyboard control. I normally use Firefox with one hand mostly idle on the keyboard and one hand on the mouse; with the scroll wheel, I wind up with the keyboard hand moving to the scroll wheel instead.

PPS: I discovered xinput via Neil Burlock, who shows a more permanent way of disabling or remapping mouse buttons if you want to do that. The USB mouse I'm using has a very generic identification string, so I decided that I didn't want to be that forceful just in case.

Thinking about how to test our UPSes

In light of my confession about our handling of ZFS disk sync, one of the vital things in our environment is working UPSes for the iSCSI backend disks. Without UPSes a building power failure would cause both sides of a mirror to lose power simultaneously, which removes our protection against losing in flight ZFS uberblock and metadata writes.

Now, one of the problems with UPSes is that their batteries eventually wear out. Often you get no advance warning about this having happened; you only find out when you lose main power and the UPS immediately shuts down. This means that you need to test UPSes every so often to make sure that they still work. For obvious reasons you don't want to do this live, with a production machine depending on the UPS.

(I would argue that you don't really want to do this even if your production machines have separately powered dual power supplies, but it's fuzzy.)

Our iSCSI backend disk shelves don't have dual power supplies, but they do have the next best thing; they're all on automatic transfer switches, with the main power supply fed from line power and the secondary power feed coming from the UPS (we did this after running into previous UPS problems). This means that in theory we can actually test all of our UPSes without having to schedule a downtime.

To do the testing we would first put an extra, unused UPS into every rack and test this UPS to insure that the battery was good. Then for each disk unit's UPS we would move the UPS side of the disk unit's transfer switch to this new known-good UPS, test the disk unit's normal UPS, and when it passes move the disk unit's UPS side back to its normal UPS. At least in theory our exposure would be limited to having a power failure in the small interval between unplugging a disk unit's UPS power feed from one UPS and plugging it into another.

(This is me thinking aloud. I don't know if we'll actually do this or if we'll want to schedule a downtime for the testing just in case something goes wrong. Certainly testing with a scheduled downtime is going to be clearly safer, because we can take the fileservers down so that there won't be problems if a backend's disks abruptly lose power due to some problem. Sometimes system administration is about tradeoffs and the balance of risks.)