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 308521 - better window resize scheme with mouse shortcut
better window resize scheme with mouse shortcut
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
constraints_experiments:targeted
Depends on:
Blocks:
 
 
Reported: 2005-06-21 13:48 UTC by Akos Ladanyi
Modified: 2005-11-19 17:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Akos Ladanyi 2005-06-21 13:48:34 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?
Comment 1 Havoc Pennington 2005-06-23 13:30:22 UTC
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.

Comment 2 Elijah Newren 2005-09-01 02:41:19 UTC
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.  ;-)
Comment 3 Elijah Newren 2005-11-19 17:15:46 UTC
[Cue Wizard of Oz music]

Ding! Dong!  The bug is dead!
The wicked bug,
The wicked bug,
Ding! Dong!  The wicked bug is dead...