GNOME Bugzilla – Bug 308521
better window resize scheme with mouse shortcut
Last modified: 2005-11-19 17:15:46 UTC
Currently when resizing a window with ALT + middle click, the direction of the window resize depends on in which quarter of the window you clicked. I think the following, more detailed scheme would be better: =========================================== |resize |resize |resize | |vertically and |vertically |vertically and | |horizontally | |horizontally | ------------------------------------------- |resize |move |resize | |horizontally |window |horizontally | | |(???) | | ------------------------------------------- |resize |resize |resize | |vertically and |vertically |vertically and | |horizontally | |horizontally | ------------------------------------------- This is how it works in openbox3, and I find this more convenient. What do you think?
the tradeoffs are there, this makes it harder to do the multi-way resize, and maybe increases errors where you click the wrong region. I think with the current setup it's pretty possible to ignore or keep subconscious that it matters where you click, with this setup it would be more "in your face" I'd probably say the presumption is against change since people will get all riled up, and since this is probably not clear-cut we may as well leave it as is. But feel free to discuss and/or ask the usability guys.
Hmmm...I'd actually tend to agree with Akos. I think the larger region of the current method for multi-way resizes isn't fully usable as such due to harmfulness of missing, and that Akos' suggestion would enable some frequent usage cases (for me at least) that aren't currently available with alt-middle click. In more detail: I use alt+middle click resize quite often, but a good percentage of the time (perhaps even most) I really only want to resize one dimension. Sometimes the other dimension being resized doesn't matter much, but there are times when it's really frustrating and I have often resorted to slowing down incredibly mid-way through the resize in order to try to keep the extra dimension from being altered (or even stopped the alt-middle click resize and then just used the window decorations). Also sometimes when I click too close to the middle, I find I'm resizing two sides that I didn't intend to resize and the side(s) I did mean to resize is(are) being left alone. Granted, I learn quickly to avoid the middle because of this (though I still get it every once in a while), but my learning is accompanied by a forced requirement to undo damage first (where damage means an incorrect movement of a corner I wanted held fixed) instead of getting a much nicer no-op or reduced-op as Akos' suggestion would provide. With his suggestion, I wouldn't have to undo anything, I could just quickly move the mouse a little bit and re-try the operation. I don't see this suggestion making the multi-way resize that much more difficult; a ninth of an entire window is still a pretty huge target--especially considering the avoid-the-middle problem that users need to learn under the current functionality anyway (see the middle paragraph). Also, contrast this ninth of the window area with the area of the window available to start a resize operation for those users who don't know about alt-click (i.e. the majority). The biggest problem with Akos' suggestion is that there's a middle ninth of the window that's kind of a dead region that is hard to know what to do with. I believe the right thing there is actually no-op (if you mean to resize, an accidental move would mean messing up what you wanted to do and require you to manually fix it), though that might seem a little weird at first and may initially confuse users who are used to the old behavior. Luckily the users won't have to undo any damage and will probably learn the correct behavior before long, but it's still a bit of a sore point. Of course, I reserve the right to change my mind after trying it out, but that's my gut feeling on this bug. ;-)
[Cue Wizard of Oz music] Ding! Dong! The bug is dead! The wicked bug, The wicked bug, Ding! Dong! The wicked bug is dead...