After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 607797 - mutter gconf key mouse_button_modifier probably shouldn't default to <Alt>
mutter gconf key mouse_button_modifier probably shouldn't default to <Alt>
Status: RESOLVED FIXED
Product: gsettings-desktop-schemas
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: gsettings-desktop-schemas-maint
gsettings-desktop-schemas-maint
: 654368 660328 666089 (view as bug list)
Depends on: 662476
Blocks:
 
 
Reported: 2010-01-22 18:09 UTC by William Jon McCann
Modified: 2013-07-04 08:26 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
wm-schemas: Change default mouse-button-modifier (1.40 KB, patch)
2011-12-13 15:50 UTC, Florian Müllner
committed Details | Review

Description William Jon McCann 2010-01-22 18:09:51 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?
Comment 1 daniel 2011-10-04 01:22:19 UTC
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.
Comment 2 Matthias Clasen 2011-10-04 20:42:56 UTC
*** Bug 660328 has been marked as a duplicate of this bug. ***
Comment 3 Florian Müllner 2011-10-10 09:20:19 UTC
*** Bug 654368 has been marked as a duplicate of this bug. ***
Comment 4 Florian Müllner 2011-12-13 14:56:21 UTC
*** Bug 666089 has been marked as a duplicate of this bug. ***
Comment 5 Florian Müllner 2011-12-13 15:03:29 UTC
Proposed change applies to fallback mode as well, so reassigning.
Comment 6 Florian Müllner 2011-12-13 15:50:30 UTC
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.
Comment 7 Bastien Nocera 2012-03-09 18:38:02 UTC
Attachment 203349 [details] pushed as 4dea8ef - wm-schemas: Change default mouse-button-modifier
Comment 8 Florian Müllner 2012-03-09 18:43:18 UTC
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?)
Comment 9 Bastien Nocera 2012-03-09 18:53:59 UTC
Reopening, then. I'll revert for now.
Comment 10 Florian Müllner 2012-04-17 22:00:49 UTC
(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.
Comment 11 Florian Müllner 2012-04-19 15:50:23 UTC
Attachment 203349 [details] pushed as 19fe99f - wm-schemas: Change default mouse-button-modifier
Comment 12 Robin Stocker 2012-10-20 14:22:05 UTC
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.)
Comment 13 Bastien Nocera 2012-11-27 09:09:37 UTC
(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.
Comment 14 Fernando Herrera 2013-02-15 21:36:31 UTC
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?
Comment 15 Peter 2013-07-04 08:26:49 UTC
+1