Window Manager Modifiers

Carsten Haitzler (The Rasterman) raster at
Fri Aug 3 20:02:39 PDT 2007

On Fri, 03 Aug 2007 08:52:24 -0700 Ted Gould <ted at> babbled:

> Hello all,
> In the Inkscape project we're constantly butting up against the problem
> where there simply aren't enough modifiers for everything we'd like to
> implement.  This means for most of our tools there is a constant battle
> to figure out how we can fit everything into Alt, Ctrl and Shift.  We
> manage.  But, many window managers are using alt click to drag windows
> which takes 1/3 of our options away.
> There are lots of solutions to this, I'm curious which way makes sense
> to people.
> - Applications could start using the "Meta" key.  I don't like this
> because it seems to be something that is rather machine specific.  I
> don't think applications should be using this modifier.
> - There is some Freedesktop spec that says Window Managers should only
> use the meta modifier for their actions.
> - Somewhere there is a spec that allows a window manager hint to be set
> by applications to say "I'd really like Alt, please!!!"
> - Some users don't get functionality out of some apps unless they
> reconfigure the apps or their desktop.
> My personal favorite here is "2" -- I think that the Meta key could be
> turned into the "desktop" key where other desktop actions could be
> assigned to it also.

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.

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.

personally- i think you need to find a way to do what you need without needing
more and more modifier keys. i know a lot of wm's will keep being shipped using
alt+button because they have been shipped that way for 10+ years. it's been a
default feature for a decade and it's not going away. you need to find a way to
work with it. i would SOONER specify "alt + button is reserved for wm's - apps
need to use anything else" because wm's "were there first", "steal the buttons
before your app can do anything about it" and "it's an incredibly useful
feature to have on ALL windows" as opposed to losing it on ALL windows just so
1 app can have more bindings.

the only sensible suggestion here i think is some form of hint on the window
that says "i use alt+button 1, alt+button 2, ctrl+button 1 etc." so the wm
MIGHT be nice and disable any of its own bindings if they conflict - just on
that window. the problem here now is inconsistent UI experience and control - i
go to my inkscape window and press alt+button 1 to drag the window and it
doesn't - it does something else. the element of least surprise is violated.
every window i have does it - except this one now. so though it is technically
solvable to give you bindings back - it now leads to a bad UI experience and
users i think will be better off if you try and stick to the pseudo-conventions
in-place? remember this problem exists for key bindings as well - you could
complain that "wm's steal alt+tab from apps - i want wm's to stop that so i can
get more key combinations for my app". it's not going to happen - there are
many common key-bindings too that wm's use and there are pseudo-conventions

------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at
Tokyo, Japan (東京 日本)

More information about the xdg mailing list