My usage patterns of late have lead me to the conclusion that something critical has been omitted with modifier keys. Modifier keys are those keys that alter the meaning of keypresses, things like Shift, Alt, Ctrl, Windows, Apple, Option, Command, Function… (I think that covers most common modern keyboards, there have been others). The omission is that no environment I’m aware of reserves a key for the system; applications are always able to intercept the key-presses and do inconsistent things with them (I’m looking at YOU old fashioned text editors). A key reserved for the system (or, actually, the window manager in most stacks) would be useful in a variety of ways, all derived from implementing truly uniform behaviors system-wide. I’ll call this magical key “Sys” (for System Key, its a surprisingly little-used phrase).
Modifier keys have always contentious (and well-storied) things; see oldschool cokebottle jokes and this story about the early Macintosh (near the bottom, that isn’t the one about the symbol, but it may as well be here too). As such, I’ll provide two motivating examples for the addition (or forceful re-purposing) of a modifier:
* I’ve lately found myself hitting Ctrl+T and starting typing a query, expecting a fresh firefox tab preloaded to a google search box. Unfortunately, this doesn’t work so well something other than firefox has focus. I would like to be able to set Sys+T to “Bring the most recent Firefox window to the foreground (or launch it if there isn’t one), and pass it the command to open a new tab.” This should be easily possible with normal NetWM (or even ICCCM) capable window managers, as far as I understand the specs. There just isn’t a good interface for it (AFIK).
* Switching between Ctrl+C/Ctrl+V and Ctrl+Shift+C/Ctrl+Shift+V for copy/paste when switching between applications that have the luxury of following modern conventions and a terminal emulator is distracting and error prone. “Break” and “Background” are useful and have precedence, so I don’t begrudge the behavior, but the “correct” solution would be to have Sys+C and Sys+V manipulate the clipboard (which is (usually, mostly) managed above the application level anyway) in a context-insensitive way.
I know there are ways to approximate this behavior; many media players allow you to set global shortcuts to control them (which may conflict and are usually flaky); most environments have conventions which are theoretically consistent across applications (which are often disobeyed, particularly by still-useful applications written before the standard was established). This isn’t what I’m talking about. The “system only” nature of the key shouldn’t be optional. The window manager should trap anything between press and release of the sys key, including the presses themselves (press and release are separate signals for most keys on every keyboard design I know of), and handle the event, leaving applications completely unaware.
I’ll probably try to adapt XFCE (which seems to have pretty good facilities for this in place already) to as much of my desired behavior as is easily possible, using the windows key as my Sys, when I next have time for a little project like this (ha…). It may even be possible simply by abusing the keyboard preferences, which would be another victory for good old flexible Linux.
