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 436257 - Cursor appearance is inconsistent
Cursor appearance is inconsistent
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
unspecified
Other All
: Normal trivial
: ---
Assigned To: Thomas Thurman
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2007-05-06 03:07 UTC by Eric Drake
Modified: 2008-02-18 00:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
patch to fix this (1.05 KB, patch)
2007-12-12 03:37 UTC, Thomas Thurman
committed Details | Review

Description Eric Drake 2007-05-06 03:07:25 UTC
Please describe the problem:
Pressing the keyboard shortcut ALT F8 puts the user into the mode where the size of the window can be changed using the arrow keys.  
When escaping from this mode, if the sizing cursor's last position was at the top or bottom left of the window the cursor remains as a sizing cursor or changes to a cursor such as an edit cursor if gedit is open in the window) instead of changing back to the regular cursor (as it does if the last position of the sizing cursor was at the right or bottom of the window).  This inconsistent appearance of the cursor I would call a bug.  I think the cursor should revert back to the standard arrow cursor no matter which location one is in when escaping from the window sizing mode.

Steps to reproduce:
1. Press ALT F8 with an open window active and not maximized
2. Size the top of the window using the arrow key.  Hit space bar to escape this mode.  What does the cursor change to ?  
3. Repeat step 2 for the remaining window locations (right, bottom, left).  Is the change of the cursor consistent ?  


Actual results:
At bottom and right positions cursor changes to normal cursor, at top and left it doesn't.

Expected results:
The cursor should be the same no matter where one's location is when escaping from the window sizing mode.  I prefer the cursor to return to a regular arrow shape as it does when the last position of the sizing cursor was right or bottom.

Does this happen every time?
Yes

Other information:
Comment 1 Thomas Thurman 2007-12-12 03:37:23 UTC
Created attachment 100797 [details] [review]
patch to fix this

good grief, if there was ever something the "trivial" keyword was made for, this is it. :)

The attached patch fixes the problem, but I'd like a second opinion on whether it's worth including it.
Comment 2 Eric Drake 2007-12-12 03:56:51 UTC
My apologies for reporting this anomaly.  I was not aware that these kinds of items should not be reported.  
Comment 3 Mathias Hasselmann (IRC: tbf) 2007-12-12 12:02:07 UTC
Thomas: For people recognizing such small glitches this patch dramatically improves sensed quality. The patch is trivial, so it should go in - IMHO.

Eric: http://en.wikipedia.org/wiki/Smiley :-)
Comment 4 Elijah Newren 2007-12-13 03:49:08 UTC
So, two points:

1) When I took a look, I was surprised that Thomas' patch modified the right and bottom borders, since I thought those already 'worked'.  Apparently, my intuition was that we should show the user that the resizing operation had ceased by changing the pointer icon.  Thomas had just assumed that whether or not the icon changed should be consistent regardless of side being resized.

2) I believe we have another bug report somewhere about returning the mouse cursor to where it originally started before the keyboard resize (or move) operation.  That may have issues of it's own (more in regards to moving the window with alt+F7 and mouse focus than other cases), but seems to suggest that users may expect the cursor to "return to normal" once the operation is complete.  So we may want to consider position + appearance here.

That's mostly as food for thought.  Maybe we should ask mpt; he always seems to have good ideas about how to handle things like this, often in ways orthogonal to anything I had considered.


Eric: Your report seems perfectly fine.  I thought at first that Thomas was talking about how simple the fix was when he said trivial, though maybe he just found it welcomely refreshing and amusing that a user would file their own bug report as trivial; it often seems that most tend to think anything that affects _them_ should be urgent or higher priority.
Comment 5 Eric Drake 2007-12-14 06:11:54 UTC
Acknowledged.
Comment 6 Thomas Thurman 2008-02-18 00:23:04 UTC
And there I go dropping it off the radar for two months. I'm sorry.

http://svn.gnome.org/viewvc/metacity?rev=3578&view=rev