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 437910 - Add the ability to select the mouse button for resize while pressing alt
Add the ability to select the mouse button for resize while pressing alt
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
trunk
Other All
: Normal enhancement
: ---
Assigned To: Thomas Thurman
Metacity maintainers list
: 431380 484269 569242 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-05-12 14:28 UTC by David Elentok
Modified: 2009-02-01 06:33 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement


Attachments
mouse button settings (5.36 KB, patch)
2007-05-12 14:29 UTC, David Elentok
none Details | Review
extended mouse button settings (6.88 KB, patch)
2007-05-12 14:51 UTC, David Elentok
none Details | Review
Patch against current trunk, and using a boolean (5.10 KB, patch)
2009-01-24 06:39 UTC, Thomas Thurman
committed Details | Review

Description David Elentok 2007-05-12 14:28:38 UTC
I'm adding a patch to allow selecting which mouse button resizes and which button opens the window menu, the setting is done via gconf
(/apps/metacity/general/mouse_button_resize and /apps/metacity/general/mouse_button_menu)
Comment 1 David Elentok 2007-05-12 14:29:42 UTC
Created attachment 88077 [details] [review]
mouse button settings

The only thing left is add a schema for it (Which I wasn't sure how to do).
Comment 2 David Elentok 2007-05-12 14:51:53 UTC
Created attachment 88078 [details] [review]
extended mouse button settings
Comment 3 David Elentok 2007-05-12 14:52:23 UTC
Comment on attachment 88078 [details] [review]
extended mouse button settings

this patch also contains the schema changes
Comment 4 Jonathan Amir 2007-12-04 16:40:32 UTC
Isn't bug 484269 a duplicate of this one?

I think this bug should be confirmed,  priority should change from normal to high, and severity should change from enhancement to normal. Just google around for this problem and you'll see that this is a serious usability issue and a sore point for laptop users and two-buttons mouse users.
Comment 5 Thomas Thurman 2007-12-05 14:32:11 UTC
*** Bug 484269 has been marked as a duplicate of this bug. ***
Comment 6 Thomas Thurman 2007-12-05 14:51:35 UTC
Thank you for your work on this!

I am thinking that adding two new GConf keys will be an unpopular move. On the other hand, I can imagine that if you *were* used to resizing and moving windows this way, not having a middle button might be annoying. (For myself, I have been using a laptop with two buttons for the whole time I've been working on Metacity and never had a problem, but that's because I use the frame to move and resize things.) Havoc and Elijah, what do you say?

As to your patch: with your patch, we process left-click (always left-click) first, and then two values which may be middle or right. This doesn't really make sense. What is needed, assuming what's given in your bug report, is a way to share out the operations "give focus", "resize", and "move" between the three mouse buttons, which your patch doesn't do. (Essentially, ignoring error conditions, your patch gives us a boolean switch.)

Also, I would very much prefer enumerated strings "middle" and "right" rather than the button numbers 2 and 3 which happen to be the ones that X assigns the buttons.

Finally, I'd like to suggest you/we consider reframing the whole thing in terms of modifier keys. A user with two buttons can't decide that they want to map the three operations to any arrangement of their mouse buttons, but they certainly have shift, alt, ctrl, and probably super on their keyboards.
Comment 7 Havoc Pennington 2007-12-05 17:49:29 UTC
If the issue is lack of a middle mouse button, one idea might be a big global flag for "no_middle_button_mode" that did something appropriate there. Then you don't lose the advantages of having well-understood hardcoded shortcuts and mouse bindings. Also in some ideal world we could even get HAL or X to tell us automatically if there's a middle button.

If the issue is what people are used to in other WMs, I don't think that is a good enough justification by itself; see http://ometer.com/features.html
"Some people are used to it" flunks the "does not apply to all possible features" litmus test for a feature rationale. We should not be adding anything, ever, *solely* based on an argument that would also justify piles and piles of other bloat, because if you take such a rationale as OK, you've effectively accepted *all* the bloat, not just the one small change we happen to have a patch for today.

"Almost everyone is used to it" *can* be a good enough justification, but I think that does not apply here. "Some people are used to it" is too broad.

As always, the first thing to do is step back and say "what problem are we trying to solve and what are all possible solutions?" - it seems the problem is on a laptop with no middle button, you have to use the window borders to resize windows, or the resize keybindings, rather than alt+middle. Is that accurate?

Then we can brainstorm the solutions:
1. a "no middle button" mode that hardcodes some different defaults in that case
2. configurable mouse actions as in this patch
3. configurable modifiers in some way as Thomas suggests
4. perhaps having to use window borders or keybindings is not that big a deal, certainly on Windows and Mac people have to do this
5.  ... your creative solution here ...


Comment 8 Jonathan Amir 2007-12-06 09:00:22 UTC
I think that your assumption about no middle button is an over simplification, and it can lead to more problems.
Take my case, for example. I have an IBM/Lenovo R60e. It actually has 3 buttons and a trackpoint (the red point in the middle of the keyboard). Here is the relevant section of my xorg.conf:

Section "InputDevice"
        Identifier      "Configured Mouse"
        Driver          "mouse"
        Option          "CorePointer"
        Option          "Device"        "/dev/input/mice"
        Option          "Protocol"      "ExplorerPS/2"
        Option          "YAxisMapping"  "4 5"
        Option          "ZAxisMapping"  "4 5"
        Option          "XAxisMapping"  "6 7"
        Option          "EmulateWheel"  "on"
        Option          "EmulateWheelButton"    "2"
        Option          "EmulateWheelTimeout"   "200"
EndSection

Notice the last two options. I am using the middle button together with the track point to emulate a wheel. Nonetheless, I can use the middle button, but I have to click in fast enough (less than 200ms). I like the current configuration. I like this configuration as it is very useful with most programs - middle-clicking links in firefox comes in handy. In fact, the only thing broken with this configuration is resizing windows with metacity.

In other words, the problem that I have (and I think many others as well) are not that I don't have a middle button, rather it is that I "gave up" on the ability to click-n-drag it, only click it quickly. I think the same thing, or similar, applies to people who emulate a middle button somehow. So even if you query hal or X you might get the wrong answer.

In my opinion querying hal or x would be the wrong solution because it remains fixated on some gnome defaults, and it opens up the possibility to a lot more problems later.

As you said, we need to look back and figure out what the problem is. In my mind, I don't understand why the user can choose the modifier keys, but can not choose the mouse buttons. I think that is the real problem. Fixing it will make gnome look better, and if sensible defaults as chosen for backward compatibility, it won't harm anyone.

A couple of other things;

1) I disagree with the comparison to Windows and Mac. Being able to resize with a mouse-and-key combination (in kde) was a killer feature that helped with my transition to Linux. I was just beginning to suffer from rsi at the time, and I was happy with not having to grab the windows borders with the mouse. It also opened my eyes - as a windows user I wasn't even aware of the possibility.

2) If almost everyone do it, rather than just some others do it, would that be convincing enough? As far as I know, kde, compiz, beryl, openbox and sawfish do it, and they don't try to query hal or x.

3) Also, I found this bug, to begin with, because this issue surfaced up as a sore point with the integration of compiz and gnome on ubuntu. The compiz config settings manager (ccsm) tries to integrate with gnome. When the user tries to change some settings that have a corresponding settings with gnome, ccsm silently refuses. As it turns out, the alt+rightbutton thing happens to be one of those.
(I tried to find a couple of bug reports related to this compiz issue to attach here, but I can't find them, sorry)
Comment 9 Havoc Pennington 2007-12-06 19:27:44 UTC
Thanks for elaborating on your configuration, that is very helpful. So the situation is not only lack of middle mouse, but lack of a middle mouse that supports dragging.

Thinking it over, a patch like yours probably is the simplest way to deal with such a custom setup.

As Thomas says, without further changes, the current patch would amount to a boolean switch, since setting either thing to button 1 won't work, and setting both to the same button won't make sense. So really the only configs are 2,3 or 3,2. Given that, perhaps we should just have a boolean switch like "swap_resize_and_menu_buttons" to avoid worrying about how to handle or reconcile all the "impossible" configurations.

Since I can't think of a better way to deal with the situation and a boolean does not create too much combinatoric-configuration-possibilities pain, maybe this is the way to go.

Getting more metaphysical though, I want to be sure to clarify the "decision framework" here:

> I don't understand why the user can choose the modifier keys, but can not
> choose the mouse buttons. I think that is the real problem. Fixing it will make
> gnome look better, and if sensible defaults as chosen for backward
> compatibility, it won't harm anyone.

Here you aren't giving a reason why; you're saying (in two different ways) "why not?" 

First way "if I can change this why can't I change that?" really just emphasizes the "slippery slope" problem. The reason why you'd be able to change modifier keys but not this would be (ideally) that we had some reason to allow changing the modifier keys that did *not* imply allowing changes to anything and everything. IIRC, keyboards vary in which modifier keys they have, so using Super can be useful when available; and some proprietary ISV applications (maybe Maya?) use Alt+click for things so we needed a workaround. Neither of those rationales apply to this case. That's what we'd be looking for in this case as well; rationales that won't imply accepting 100 other features too.

Second way "it won't harm anyone" is used to argue for pretty much every feature request ever requested, I assure you ;-) and it simply isn't true if you take all those requests in the aggregate, though it is true if you take only one of them. 100 "harmless" features = one very harmful bloated, unmaintainable, crappy product. 1 "harmless" feature, sure, is fine.

The important thing is _why_ - what are the arguments here that apply to this feature, _but not to piles and piles of others_

I'm not trying to be a pain, this is genuinely important to keeping a high-quality product, and I think it's always worthwhile to re-emphasize.

One clarification re: point 2), the issue is not whether other WMs do it. In fact, if metacity were going to be the same as other WMs, there would be no point in working on metacity. The purpose of metacity is to add an additional, *different* choice, which is not accomplished by being the same as the existing choices.

What I was trying to say is that if almost every *person* is used to the feature, that's an argument for adding it. Here I'd be talking about computer users generally, too, not only Linux users.

One other comment, I don't think "user can choose modifiers but not buttons" is the right formulation, and the reason is that it presupposes a solution; it isn't a user goal. Nobody's *goal* is to "configure mouse buttons." The *goal* is something like "resize a window quickly and easily," I would think.
Comment 10 Jonathan Amir 2007-12-07 19:15:35 UTC
Thanks for your elaborate reply. It seems that I haven't explained myself properly, so let me try again.
First thing first, I guess the way I related the modifier keys to the mouse buttons is wrong. Nonetheless, I still feel there is enough justification for the why.

The current situation is that the mouse buttons are hard coded in the code. I think that so far there are two solutions being discussed:

1) The boolean flag to swap buttons 2 and 3.
2) An option to choose which button to bind to resize. This is my preferred solution.

Regarding bloat: as far as I understand, both options involve adding a key or two to gconf, as well as adding a corresponding ui for it. So I don't see how the discussion about bloats is relevant, since both solutions add something to the ui.

I feel that the first suggested solution solves the user's problem (no ability to resize) but doesn't solve the real problem for it (hard coded values). Further more, it exposes the user to this rational by exposing the swap flag through the ui.

My gut feeling is that this is awkward solution. As a user, I feel comfortable with settings that I understand their rational (and in a way, their origin in the code). Choosing modifier keys and buttons (probably in the same dialog) for binding seems normal and natural to me. On the other hand, choosing to swap buttons 2 and 3 will make me wonder why I need to do it, and then wonder what do those buttons do to begin with (notice that the current dialog doesn't even mention the resize issue). Also, coming to think about it, I might also wonder if this option is similar to the option of a left-handed mouse, which swaps all the buttons (Windows has such an option, I don't know about gnome).
(I think the same argument applies not only to users but to other developers as well, but I shouldn't take the discussion to this direction, since I am not involved in the development. All I want is to be able to resize with the right button :) )

To summarize, I think that the hard coded values should go away. This is essentially my answer to the "why". If the biggest difference between the two solutions is a couple of gconf flags, but the second solution provides cleaner code and a more intuitive ui, then I'd prefer the second solution.

Regarding "it won't harm anyone", I meant to say that with sensible defaults (keeping the binding to the middle mouse for backward compatibility) this feature won't disturb old-time users. Again, I apologize if I didn't explain myself properly.

Finally, about metacity being a different choice and separating itself from the crowd of WMs, that is a good way of thinking, as long as you are not trying to be different just for the sake of difference.
Comment 11 Thomas Thurman 2008-03-01 01:37:02 UTC
*** Bug 431380 has been marked as a duplicate of this bug. ***
Comment 12 Thomas Thurman 2008-03-01 01:38:05 UTC
This same issue is also discussed in Ubuntu's brainstorming site:
http://brainstorm.ubuntu.com/idea/1511/
Comment 13 Denis Leroy 2008-03-13 11:20:32 UTC
Just a quick comment on this.

I've been using the alt-mouse combo to resize my windows exclusively for years, since I find it much easier than having to aim at the window frame/border (which to me is a slow and awkward operation, we can't all be counter-strike experts :-) ).

The problem with the middle mouse button is that on a large number of mice on the market, the middle mouse is actually a small mouse-wheel button. It's clickable, but it's a smaller and less comfortable button. While the middle-click is doable, however the click-and-drag operation is particularly awkward since you tend to accidentally scroll the mouse wheel while moving the mouse, which causes unexpected side-effects.

The situation is much worse with a more recent USB wireless Logitech mouse I purchsed (those designed for carrying along with laptops). The middle mouse wheel/button has also left and right scrolling capability. With such a mouse, the alt-middle resize operation is a frustrating experience, and impossible (literally impossible) to accomplish: because while you maintain the middle button-wheel pressed and move the mouse, any slight finger pressure to the left or right will generate a new mouse click event (the left and right scroll) which will interrupt the resizing operation.
Comment 14 Ray Van Dolson 2008-05-14 06:01:13 UTC
This seems like a no-brainer.  The main reason should be not that people are used to this in other WM's, but that it is the more flexible option (especially for those of us on laptops or with scrollwheels which is a large % of users).

As long as it's configurable, it doesn't matter if you leave the default at Alt-Middleclick.  We can change the modifier key, why not the mouse button?
Comment 15 Thomas Thurman 2008-05-28 02:43:57 UTC
Ray: Your comment makes me wonder whether you read the preceding comments, especially comment 8 where exactly the same question was asked, and comment 9 where it was answered.
Comment 16 Ray Van Dolson 2008-05-28 03:02:14 UTC
(In reply to comment #15)
> Ray: Your comment makes me wonder whether you read the preceding comments,
> especially comment 8 where exactly the same question was asked, and comment 9
> where it was answered.
> 

I have read the comments.  As it stands now it sounds like applying our own patch is the best solution.  I understand you guys don't want to add a feature "just because".  What is the process for bringing something up for official inclusion in Gnome and what is the metric for defining enough evidence for it to be considered a worthy feature?  I know by nature Gnome is resistant to change, but there must be a way to get good and harmless feature additions like this one to be considered.

You don't need to worry about a slippery slope type situation, if the same standards are applied to each RFE the good features (such as this one) will be approved and the bad ones will not.

As I see it the reasons FOR adding this as a feature:

 1. You already offer the ability to change the modifier key.  It follows that one should also be able to change the buttons.
 2. The current setup eliminates a small (but important) subset of users from being able to use this feature (which is a feature that truly helps set aside the WM from other environments)
 3. Other WM's offer this feature (XFCE's, KDE).
 4. The impact of this change is extremely low.  Default can remain the same, and users will only be presented with the configuration option if they look for it.

Reasons against:

 1. Slippery slope.  IMO if the same standards are applied for all RFE's this shouldn't be an issue.  Some will be added some won't.

That's about all I can think of.

I'm probably being clueless about something and I'll peruse the Gnome site and discover the proper way to push an RFE.  Seems to me it will most likely be with persistence on us the end user's part.

No offense meant of course, to me this seems like an obvious feature to add and I haven't really read good reasons to the contrary. :)

At least we have the source so we can maintain our own patches!
Comment 17 Nick Welch 2009-01-10 03:28:24 UTC
I strongly support this.  I am currently using my own slightly modified Metacity just to gain the ability to resize with the right mouse button.  Resizing with modifier+click is presumably a much more common task than opening the window menu, and the right mouse button is generally much more natural and comfortable than clicking the wheel.  It makes me wonder why this configuration was chosen in the first place -- multiple other WMs use the left/right buttons for move/resize, and I'm not arguing from an "everyone else does it" stand point, but rather arguing that they do it that way because it makes the most sense.

I also don't understand the strong resistance to adding more options in gconf.  Novice users will never encounter them, and picky people will be more satisfied.  I sort of understand the argument that Metacity's supposed to be simple and for common users, but at this point Metacity has such a giant advantage in maturity/correctness/development attention over nearly every other WM that it's a compelling WM for even advanced/picky users.  Have some sympathy for the nerds!
Comment 18 Jonathan Amir 2009-01-10 03:55:46 UTC
Nick, I also don't understand this resistance. The arguments shown here don't make sense, so I just gave up.

I totally agree with you about gconf. Besides, if the number of keys added is proportional to the feature requested/implemented, then it is not bloat, it is normal software evolution.
Comment 19 Havoc Pennington 2009-01-10 08:34:36 UTC
People seem to be adding "vote" comments due to perceived "resistance" to this bug, but if you read say comment 9, I already said a patch for this could go in a long time ago.

I'm not an active metacity developer anymore, and don't get a vote on this bug, so it doesn't really matter what I said, but, on the other hand, the current maintainers haven't disagreed.

There isn't some big debate about whether a patch is required. It's clear that there's a problem with some types of mouse not having a middle button or having a funky scroll button. It is not 100% clear what the exact patch should be, but discussing that, then working on it is what's needed. And the patch is going to be trivial, just as the attached patch is.

Anyway, the discussion here should be about exactly what the setting or solution should be, not about whether there should be a setting or solution. Everyone seems to agree there should be one.

The controversy on the bug so far appears to be over whether to store resize=2,menu=3 or a boolean in gconf, which is hardly a huge raging controversy. Figure it out. From an end user perspective, there isn't even a difference in what those two would allow (unless you have the kind of mouse with buttons 8 and 9), because only 2,3 and 3,2 would actually work, given the attached patch. So either way there are only two choices.

> Metacity has such a giant advantage in maturity/correctness/development
> attention over nearly every other WM that it's a compelling WM for even
> advanced/picky users.

For the record, the _reason_ metacity works well is that it doesn't have tons of featuritis and every feature was put in with the kind of what-is-the-root-problem analysis I tried to explain in comment 7, comment 9, etc.

Other WM developers put their effort into figuring out what happens if you map 2 actions to the same button, or two buttons to the same action and press them both at once, or whatever. Well, that kind of thing takes a ton of time and effort and it creates bugs.

The patch on this bug is pretty good on this dimension really, it keeps most of the existing simple hardcoded approach. It does not start trying to support some kind of arbitrary "event to action mapping," it just lets you set specifically the resize and menu buttons. It deals with the corner cases sanely, but by choosing an arbitrary answer; e.g. if you set resize or menu to button 1, my guess is it just won't work, button 1 will still move the window. If you set both resize and menu to the same button, an arbitrary one of them wins. The only two settings that make sense are "2,3" and "3,2". The patch still grabs all three buttons even if they are set to "0" or something, so you can't "disable" any of the buttons and pass them through to the app, so the patch maintains the situation where apps are discouraged from using default WM bindings.

Since only 2,3 and 3,2 in fact work properly and as expected, I'd still suggest just having a boolean, so people aren't sitting there wondering why button 1 won't work, or why if they change only one of them it doesn't work (if you change just one, then they'll conflict, and one would arbitrarily "win").
Having a boolean setting show up in the UI as two integers is just odd, imo - you're making people guess at the two magic combinations. They may not even realize the other setting is relevant, they don't necessarily appear side-by-side in the UI. So it may not be obvious that you've set "3,3" and the other "3" is overriding the one you set.

Why make it possible to set a broken state?

Anyway, if I were actively hacking metacity and wanted to solve this issue, that's what I would do. My .02
Comment 20 Phillip 2009-01-23 06:46:35 UTC
I agree with Havoc.  Being able to simply switch between "2,3" to "3,2" configuration would satisfy me completely.  Please do us laptop users a favor.  I'm tired of having to maintain my own patched metacity.

I created bug 431380 about 21 months ago (which was marked as a duplicate of this bug, even though mine came first; go figure).  Please metacity developers; don't make me wait any longer.
Comment 21 Thomas Thurman 2009-01-24 06:39:09 UTC
Created attachment 127147 [details] [review]
Patch against current trunk, and using a boolean

This patch applies cleanly to current trunk and uses a boolean instead of the two ints.  I think this is good to go in if anyone would like to verify that it works for them as well.
Comment 22 Patryk Zawadzki 2009-01-26 10:01:14 UTC
I'd like to propose something slightly bigger for 2.27 or later.

1. Ask HAL/DeviceKit for a list of mice
2. Determine the highest number of working buttons (if one mouse has 2 and another has 7)
3. Show a list of sensible buttons (ignore wheel, show names where applicable) allowing to bind an action to each of them

Mockup:

Modifier: [ Alt   ↓]
Operations:
  Left mouse button:   [ Move window   ↓]
  Right mouse button:  [ Resize window ↓]
  Middle mouse button: [ Do nothing    ↓]
  Button 7:            [ Exposé        ↓]
Comment 23 Thomas Thurman 2009-01-26 14:30:42 UTC
I think that idea has merit: it seems to be no more than an extension of the idea of keybindings.
Comment 24 Sharif Nassar 2009-01-26 21:18:00 UTC
*** Bug 569242 has been marked as a duplicate of this bug. ***
Comment 25 Matt Kraai 2009-01-27 18:52:23 UTC
(In reply to comment #21)
> Created an attachment (id=127147) [edit]
> Patch against current trunk, and using a boolean
> 
> This patch applies cleanly to current trunk and uses a boolean instead of the
> two ints.  I think this is good to go in if anyone would like to verify that it
> works for them as well.

The patch adds a /schemas/apps/metacity/general/mouse_button_menu schema which doesn't appear to be used anywhere.  This appears to be cruft from the previous patch.

The patch also does not include a space before the question marks in meta_prefs_get_mouse_button_menu and meta_prefs_get_mouse_button_resize, as is done before the question marks elsewhere in that file.

That said, the patch worked for me when I applied it on top of 2.24.0.
Comment 26 Thomas Thurman 2009-01-27 21:06:41 UTC
Matt: thanks for your help.

Committed as http://svn.gnome.org/viewvc/metacity?rev=4091&view=rev with your changes.
Comment 27 Denis Leroy 2009-01-27 21:09:43 UTC
This is great news, thanks!
Comment 28 Matt Kraai 2009-01-27 21:19:14 UTC
Oops.  I didn't notice it before, but the changes to prefs.c also omit the spaces before the colons in the conditional expressions, unlike the other such expressions in the file.  Not sure if this is worth changing now, though.
Comment 29 Matt Kraai 2009-01-27 21:22:59 UTC
I also failed to notice that the change made to the /schemas/apps/metacity/general/mouse_button_modifier schema indicates that the left and right operations can be swapped, whereas it should say that the *middle* and right operations can be swapped.
Comment 30 Phillip 2009-02-01 06:33:50 UTC
Thanks a million!!