GNOME Bugzilla – Bug 607797
mutter gconf key mouse_button_modifier probably shouldn't default to <Alt>
Last modified: 2013-07-04 08:26:49 UTC
mouse_button_modifier seems to default to <Alt>. I'm not sure this is a good idea. It interferes with at least a few programs (Inkscape being one). I'm not sure the functionality that it provides is really that interesting either. Maybe unset by default? Or <Super> since we kinda take over the Windows key for WM functionality?
Agree that it's a problem. It's also a problem for gimp, so I always switch mine to <Super>. But please don't get rid of the mouse_button_modifier functionality. I use it all the time and would be very irritated by being required to grab for the title bar every time a window adjustment is required. Super can work though. If you press the Super key but don't initiate a drag, then it just continues to execute its default action.
*** Bug 660328 has been marked as a duplicate of this bug. ***
*** Bug 654368 has been marked as a duplicate of this bug. ***
*** Bug 666089 has been marked as a duplicate of this bug. ***
Proposed change applies to fallback mode as well, so reassigning.
Created attachment 203349 [details] [review] wm-schemas: Change default mouse-button-modifier Some applications (mostly graphics) use alt-click and alt-drag for actions, which conflicts with the current default; change the default modifier to <Super>, which is already prominently used as overview key, so using it for other window manager functionalities is pretty reasonable.
Attachment 203349 [details] pushed as 4dea8ef - wm-schemas: Change default mouse-button-modifier
Unfortunately using <super> as modifier is currently broken (see the bug dependency below), so we should probably revert the patch for now and reopen (or is the intention to kick my butt to update the patch in the other bug?)
Reopening, then. I'll revert for now.
(In reply to comment #9) > Reopening, then. I'll revert for now. A fix for bug 662476 has been pushed, so the patch may be reapplied (or the revert reverted ;-)). Sorry for the delay.
Attachment 203349 [details] pushed as 19fe99f - wm-schemas: Change default mouse-button-modifier
Guys, I really appreciate what you're doing. But for the next time, such a change MUST be mentioned in the release notes, e.g. here would have been a good place: http://library.gnome.org/misc/release-notes/3.6/users-core.html.en I see that there is a "relnote" keyword for such uses. (I just upgraded and was wondering why Alt + move stopped working.)
(In reply to comment #12) > Guys, I really appreciate what you're doing. But for the next time, such a > change MUST be mentioned in the release notes, e.g. here would have been a good > place: > > http://library.gnome.org/misc/release-notes/3.6/users-core.html.en I blame the maintainer.
Well, I think just a mention in the release notes is not enough. Such change is a big change for a lot of users. Actually for me it was the most painful change on the Fedora 17 -> Fedora 18 upgrade. Alt+Button1+Drag has been the way of dragging windows in Linux for more than 15 years in almost every window manager. I agree with whole interaction changes in updates like GNOME 2 -> GNOME 3. But this change in a minor release is too painful for users used to the old behaviour (I say old because I know that metacity used super+Button1+Drag since 2003, but keeping the old behaviour working). Also notice that dragging windows is a very common thing nowadays with two monitor setups and dragging fullscreen windows can only be done using this technique (no titlebar). I use it all the time to drag media player fullscreened "windows" to my second monitor (watching movies and youtube on big tv). So, what about adding back the Alt+Button1 behaviour?
+1