[Inkscape-devel] Window Manager Modifiers

jiho jo.irisson at gmail.com
Sat Aug 4 09:51:28 PDT 2007

Hello everyone,

First of all, it was not my intention to start a flame war or  
anything. It is just my personal opinion that what lacks the more  
cruelly to Linux desktop currently is consistency and keybindings is  
one particularly clear example. I hoped that mentioning it on this  
list, where the problem is regularly brought up, would get the ball  
rolling to the correct people (be they freedesktop or someone else).  
Anyway, I happily use Mac OS X (where keybindings are quite  
consistent and can be edited easily anyway) and won't "fight" for  
linux to get better... I just hope it will, because I like the  
development model more ;-)

That said, here are my two more cents (or maybe three...)

Some quick math first: suppressing a key from the three available to  
applications does not suppresses only a third of the possibilities,  
indeed those things are multiplicative. With 2 modifiers and 10 keys  
on a keyboard you have
	2 * 10 + 1 * 10 = 30 possibilites
(2 modifs, 1 combination). With three you now have
	3 * 10 + 3 * 10 + 1 * 10 = 70 possibilites
(3 modifs, 3 two-way combinations, 1 three-way combination).
Now add the mouse and things are getting worse.
So the decision here is important as it severely impacts the  

On 2007-August-04  , at 05:31 , Ted Gould wrote:
> On Sat, 2007-08-04 at 12:02 +0900, Carsten Haitzler wrote:
>> well... this is no new problem. it's been around for years. in the  
>> end - the
>> wm's win, because you need one for a sane desktop. whatever they  
>> steal in terms
>> of key (and mouse) bindings is what a user comes to EXPECT from  
>> functionality
>> on ALL their windows (eg - alt+left mouse to move, alt+right mouse  
>> for wm
>> window menu etc.). there is a kind of pseudo-standard (just by  
>> virtue that a
>> lot of wm's come this way by default) that there seems to be a  
>> common convention
>> that alt + button is what wm's take - anything else if open for apps.
> I guess my real concern is that it's alt today, meta tomorrow and
> control next week?  It seems like in general that there should be some
> consistency here.  That way someone knows where their mouse events are
> going (though I doubt they'll think about it that way).

If I recall correctly (and I am quite sure I do) Gnome also uses CTRL  
in some keybindings so this can indeed be an additional problems (see  
the quick computation above)

>> now i ask - why do u think it's bad apps use met - but you now  
>> promote wm's to
>> use it instead of alt? you are basically saying "i don't want to  
>> use meta - so i
>> want to force wm's to do the thing i am not willing to". at the  
>> end of the day
>> - this is highly unfair as your point about the meta key being  
>> "not always
>> there" is valid - and all you do is put the problem onto the wm's.
> No, the reason that I was suggesting that a WM use meta is because in
> general, I think the desktop knows a lot more about the hardware that
> it's working with.  Application do, and should, know very little.
> Things like accessibility and keyboard configuration are done at a
> desktop/WM level -- so I thought it would make more sense to also use,
> or not use, the meta key at that level.  I believe that there are also
> internationalization issues here, though I'm ignorant to other  
> keyboard
> layouts myself.

Let's assume everyone agrees that WM/Desktop and Applications  
keybindings must be separate (I think that's quite safe). Now the  
question is which modifier for which, and the choice is between ALT  
and META. Here are a few reasons why I think ALT is better for  
applications and META for WM:
- keyboard proximity. CTRL is *the* application level shortcut and  
ALT is closer to CTRL than META on all keyboards I've seen, so CTRL 
+ALT combinations for applications seems more natural than CTRL+META
- WM keyboard shortcuts they are kind of special since they apply  
across the board and to me META carries this idea of "special".
- META "uncertainty". as some pointed out, META isn't always  
available (though I think it must be a very small minority of cases,  
since I've seen some pretty exotic Sun and IBM keyboards and there's  
always a META key somewhere, sometimes where CAPS LOCK usually is) or  
may change "appearance" (it is the WIN key on windows PC keyboards,  
the apple key on macs, a real META key on some others etc.). So it  
may be less accessible.
	. as Ted just pointed out, it is easier to fix its absence (ie.  
remap some other key) at the desktop level than at the application level
	. the annoyance it creates when it changes position or form is  
restricted to one area (windows manipulations) instead of applying to  
several keybindings in several apps. it is, in my opinion, easier to  
	. even if it is completely absent, or difficult to reach, most  
window managing actions can be performed with mouse clicks and drags,  
on windows or in menus. In fact, most people do not actually use  
window manager keyboard shortcuts. This is not the case for many  
places where ALT is currently used in Inkscape (or in Gimp for that  
matter). Some important things are simply *not possible* if you don't  
have a second independent modifier in Inkscape or Gimp. And this is  
not a problem of design in either apps, it's just that there are so  
many things to do that you need many modifiers (I tried to report  
everything that can be done with the selector tool in Inkscape and  
its associated modifiers and this is already very complex and nearly  
I am not saying that WM/Desktop keyboard shortcuts are useless, I am  
just saying that they are probably  less numerous than what a large  
app would need so it is less pain if they are difficult to reach or  
need to be re-learned.

So there is history carrying over its early habits and there is what  
some "unifying" projects like FreeDesktop can specify, and maybe  
change, in the name of better overall usability. I think this issue  
is typical of the second case and I hope my examples have convinced  
some about this.



More information about the xdg mailing list