I'd generally agree with the caveat that I'm ignoring all keybinding
conflict issues until I add keybindings preferences.

Want to switch to windows key for a lot of things perhaps.

Who should switch to the Windows key - metacity or nautilus? What is
the Windows key on normal keyboards anyway?

I guessed that you had some keybindings preferences because someone on
#gnome said they had modified their bindings in metacity. 

I think the window manager should maybe use the windows key.

People change their metacity bindings but it involves 
using the control center (aka "cc") to parse the config file 
"keybindings.c" ;-)

I'm marking minor, since I'm pretty close to nautilus and there hasn't
really been much expressed desire to use alt+mouse bindings. It has
also been on by default in sawfish1 for ages, without too much adverse
impact on gimp of which I'm aware- at least, the problems aren't
reflected in Ximian bugzilla or GNOME's. [As usual, I'm open to
discussion here, though.]

By the way, on nautilus you can drag and then press Alt. It works fine
then.

It doesnt interfere with the Gimp AFAIK, or does Gimp use alt-*drag*
for anything? 
What comes to gimp's layer-cycle with alt-tab, I think a lot more
people know alt-tab to cycle windows instead of layers, so Gimp is
definitely a minority. plus you can cycle layers in the Gimp with
PageUp/PageDown. (Shift-page* to move them btw)

After GNOME2 I will review the keybindings/mouse-click-modifier-keys
in Nautilus again, in light of recent changes. Then I will see whether
this is still a problem.

Gimp uses the Alt-Drag feature - you can move selections without
their content around. Also the path tool uses Alt-Drag to move the
whole path around. Also I'd recommend to do the same as sawfish and
allow to define a Window-Manager Modifier, that might get used in
Keyboard shortcuts. I'd set the default to Meta (usually the Windows
Key is mapped to this) and if somebody has a keyboard without this
he can set it to Alt without having to change all keyboard shortcuts
manually.

BTW: I disagree with the classification as "minor". Gimp Users have
been bitten by the disabled Alt-Key by lots of window managers. While
this seems like a minor problem it is a fundamental problem: Is the
Alt-Key available for applications or isn't it? Is the availability of
the Alt key something where application developers can rely on?

IMHO two modifiers (Shift and Ctrl) are not enough for all
applications, which is the reason why I am an advocate of the usage of
less common modifiers for global tasks like window managing.
Discussing this on the level of "Alt works fine in nautilus if you
press it after the mouseclick" is IMHO a bit short sighted.

(BTW: These kind of bugs have been in Bugzilla for Gimp a lot IIRC,
but they get closed quickly, since they are not bugs in Gimp and you
can usually reconfigure your window manager to use different modifiers)

My impression was that metacity was started to get an easy,
not-configuration-bloated WM that doesn't overly stress
users coming from Win or Mac.

IMHO it should not allow users to configure "ALT" for any
shortcut. That's what Windows, Apple and Meta keys are for.

Shift, Control and Alt should belong completely to the
application. Making this configurable would just continue
the current confusion and people will continue to wonder
why Alt-drag in GIMP works on machine a but not on b.

I never heared of a Phtoshop user who had to reconfigure
her finder to get some shortcuts running. It just works
by default and it always works.

Stealing keys from applications is IMHO unacceptable if
GNOME2 wants to call itself user friendly.

Unfortunately many keyboards do not have a windows key, even on
systems you can purchase today. e.g. Owen's new IBM laptop doesn't
have one, I believe.

The reason this works on Mac and Windows is that they have hardcoded
system shortcuts, such as Alt+Tab or Ctrl+Esc, and the shortcuts are
not configurable, and so apps avoid those keys. It's that simple.
There are tons of keybindings on Windows that are "stolen" from apps.

You guys said yourself that Gimp always closes "these key shortcuts
collide" bugs by saying "configure the window manager" - i.e. the
reason things are broken is that the WM is configurable. ;-)
If the WM wasn't configurable you guys would have to just pick another
keybinding.

That said I think the WM has to be configurable in practice for now,
because things are broken. So Alt+button1 to drag probably should be
configurable in metacity.

How we get out of this catch-22/chicken-and-egg fuckup so that things
work out of the box, I don't know - maybe others have ideas.
It helps a bit that Calum has documented keybindings, and metacity is
using basically the same bindings used by Windows, Motif, Kwin in many
cases.

Just chiming in here - I've recently installed RH8 on a 
workstation intended for work in visual FX.  M.N.'s comment about 
leaving alone Alt key equivs voices a long-standing problem I've 
had with Linux wm's in general for some time, but in this case 
it's become something more than a nuisance - you literally 
*cannot* run two of the major applications for FX in Metacity 
because of this - Houdini and Maya.  How close are we to being 
able to turn off metacity's grabbing of Alt-Mouseclick events?

thanks

J.C.

Created attachment 11440 [details] [review]
Patch to add configurable modifier for the <modifier>+click actions

Patch is in CVS. 

I left the Alt+click stuff on by default for now, but I'm not sure
where to go with it.

The only thing that works IMO is to have standard documented system
keybindings and for apps to not use them, exactly as Windows/Mac 
work.

The question is really whether Alt+click is more useful as an
application feature, or more useful as a window manager feature.

Gimp hackers: I hope you will not tell people to "configure their WM"
when they say their are keybinding conflicts with gimp - 
we really should adjust things to there are not conflicts by default.
Saying apps should own Ctrl/Shift/Alt entirely does not work, 
there are no other modifiers that are reliably available, plus 
the standard keybindings from CUA/Windows/OS2/Java/Motif often 
use Ctrl/Shift/Alt. So we need to allocate the default bindings 
between apps and WM, avoiding conflicts.

The mouse is especially hard here as there are only 3 buttons x 3
modifiers available... unless you add modifier combos, I guess.

cc'ing UI team for comment.

Just some random thoughts:

- some counting: Modifiers are a way to quickly transiently change the
behavior of the mouse. With just two modifiers available for
applications we have just four transient modes for the left
mousebutton - not really much: Gimp for selections alone currently
needs five: REPLACE, ADD, SUBTRACT, INTERSECT and MOVE; a 3D
application probably needs more for quick navigation and object
manipulation. The right mousebutton is usually used for context menus,
all other mousebuttons must not play a vital role in an application,
because they are not always available.

- FVWM has the feature that the window manager passes all keypresses
to the application when the NumLock Key is pressed. I personally
dislike this feature (when accidentially switched on) but it might be
kind of a "solution" to this dilemma.

- ALT+key usually gets interpreted by the application for mnemonics
(on GTK2 and Windows IIRC). This basically forbids its usage for
keyboard shortcuts for the window manager. The window manager IMHO
should have a consistent modifier for its operations (mouse and
keyboard). The Modifier on the "Windows Key" is perfect for this - if
it exists on the Keyboard. Since this is not always the case the
fallback could be a combination like ALT+CTRL.

My current favorite idea is to move Alt+click to "Super+click"
(Super is what windows key is normally bound to, I _think_ - if 
not it's hyper), and if you don't have a windows key, you have 
to manually configure it to use Alt instead.

Other bindings such as Alt+Tab and Alt+F4 are very standard across
platforms, so I think it's right to leave them on Alt.

I think the numlock trick would confuse people - well, I know it
would, as the naive window manager implementation of keybindings 
does this accidentally, and I had a lot of confused people
when I did that. ;-)

> Shift, Control and Alt should belong completely to the
> application. 

As modifiers for mouse operations perhaps, but as modifiers for
keyboard operations Alt will probably never be reserved for the
application's exclusive use as long as there's a CUA window manager
spec that most desktops follow.

I changed the default to Super+click in CVS. Here comes the 
FAQ and complaints. ;-)

Anyway, on keyboards with a Windows key it would typically get mapped
to that, if configured correctly.

I noticed that Red Hat 9 has both alt-move and super-move. GNOME 2.5
still has alt-move only, instead of the super-move that I would now
expect. Is this actually in released tarballs?

The decision was changed at some point to have Alt on by default. I
don't remember which bug number has the discussion.

Just for reference for anyone that runs across this bug, I believe the
other bug Havoc was referring to in his last comment is bug 101151.