GNOME Bugzilla – Bug 97703
maximize button doesn't extend to top-right pixel of frame (fitt's law)
Last modified: 2006-08-07 18:06:35 UTC
I've been using metacity as it comes in RH 8.0 (bluecurve theme). But I noticed that if a window is maximised (which most of mine are), and you scroll the mouse into the top right hand corner and click, it actually doesn't activate the close window button. The same applies for the top left corner, or anywhere along the top. I don't alway believe in fitts law... but in this case, when you have a window maximised, I think it should apply to the top and top corners. metacity and rh 8.0 rock, by the way. Good work.
If I understand bug 82542, this is a function of the theme, rather than Metacity itself.
I think maybe I've misunderstood things. Please disregard my comment above.
I would expect this is a theme issue, though I haven't verified for sure.
This is true for all Metacity themes that I have (Bluecurve, Crux, Grand Canyon, High Contrast, Large Print, Mist, Ocean Dream, Simple, Smokey Blue and Traditional). Should I start bugging all the creators of those themes or is there a chance Metacity could get a feature eliminating the border above the widgets, when in fullscreen mode?
Why should clicking in the top-right corner, as opposed to the close button, close the window? I don't get what you're trying to say...
you should do a google search on 'fitts law' basically, the close button, in a maximised window, 'purports' to be in the top right hand corner, but that is not what the user experiences when they roll the mouse very fast into the top right hand corner and click. it's bad UI
I do think this is probably the theme's fault; you might look to see if all these themes have some kind of padding around the button.
*** Bug 131325 has been marked as a duplicate of this bug. ***
Well metacity should disregard what the themes think, when it is dealing with a maximised window. There are many times i have tried to close a maximised window by flicking the mouse into the top right hand corner and clicking, but all this does is grab the window like i want to move it.
metacity could probably extend the "hot area" of buttons to the edge of the frame always. you'd have to look at the code to see how hard that is.
Created attachment 23788 [details] [review] cheap-ass hack to the simple theme to do this
I hacked the simple theme so it works like I want it to. I changed the normal_small_borders frame definition to have no left and right borders by overriding button_border. Then I increased the button_height attribute until the top line became clickable. I set it to 20, but that is probably dependent on the font you used. Now it worked like I wanted it to, but the buttons were a bit too high, so I duplicated the button drawing functions and made the maximized state of the frame call those instead. - What is the point of the button_height attribute? Why not expand the buttons to fill the space? - Perhaps there is a way to center the image relative to the available space? IMO the themes should not have a left and right border for the title bar in the borderless frames. That would be half of the problem solved without hacks.
Just a little observation, it works for me with the "Esco" theme. Not only the close button, but also the window menu works by clicking the top-left pixel.
Someone mailed me a URL, which is somewhat related to this bug. http://www.asktog.com/columns/022DesignedToGiveFitts.html (see Question 5)
just installed fedora core 2 (bluecurve by default). the problem is still there on the default fc2 theme.
Coupla things: 1. I just noticed that in Windows XP the top right pixel does close the window. This is in spite of the fact that close button doesn't *look* as though it extends to the corner. 2. Someone mentioned elsewhere that Fitt's law shouldn't apply for "dangerous" operations. I feel that closing a window should not be considered dangerous from the point of view of the window manager, because if there is potential dataloss then the app should warn the user before exiting (as most apps already do). P.S: Thanks Davyd.
See this GNOME mail list post for additional details: http://mail.gnome.org/archives/gtk-list/2003-June/msg00308.html This is an annoying little bug. It shows a lack of fit and finish.
Guys, everyone agrees this should be fixed, no need to post comments to that effect. Instead, post a patch that always extends the "hot area" of the corner buttons all the way to the edge and top, and always extends the "hot area" of non-corner buttons all the way to the top. Code is what we're missing here.
Removing accessibility keyword, not sure it's pertinent here.
IMHO, this is a pretty serious bug that really hurts usability. I'm running with a modified Simple theme with the button_border and title_bar_borders all set to zero and it works fine. I can push the mouse into the corner and click to close a window or maximize it. Seeing as nobody seems to have time to fix this in code (this bug was reported in 2002!), why not modify at least the default theme that most users will use to not have any button_borders?
*** Bug 158653 has been marked as a duplicate of this bug. ***
Ubuntu Linux has a fix here similar to the Simple hack AFAIK: https://bugzilla.ubuntu.com/show_bug.cgi?id=2655 http://people.ubuntulinux.org/~jdub/ubuntu-artwork_0.2.15-1_all.deb
How come Clearlooks wasn't designed with Fitt's law in mind? Just like the venerable "simple" theme, it doesn't use Fitt's law to extend to the top-right corner.
Comment on attachment 23788 [details] [review] cheap-ass hack to the simple theme to do this This patch is backwards (it still applies cleanly with -R, though)
*** Bug 333939 has been marked as a duplicate of this bug. ***
*** Bug 341516 has been marked as a duplicate of this bug. ***
Created attachment 70101 [details] [review] Make it possible to click above and beside the buttons as well as on them I think it's a bad idea to fix this by modifying themes. Firstly, a theme might quite reasonably want to have a border around windows, and secondly, there are dozens and dozens of possible themes. I think this patch is a better way of going about it. It defines two GdkRectangles for each button: "actually", which is the rectangle in which the image is drawn, and "virtually", which is the area which is sensitive around the button. For the button on the top right, this extends to the top and rightmost edge of the window.
When I read Thomas's patch, my first thought was "how come the 'actual' button is not the area that can be clicked?". I'd suggest naming them 'visually' and 'clickably' to remove any such possibility for confusion.
patch looks good. oa's naming suggestion seems sensible too
Over coffee, a coworker pointed out to me that this patch is wrong. It should only apply to maximised windows, right? (Or have I misunderstood?) Otherwise you can't resize a non-maximised window using the top right-hand corner without then closing it. I'll fix that this evening.
Created attachment 70289 [details] [review] Same again, but only works when maximised and has better field names Here's the new patch, substantially the same as the old patch, but only working on maximised windows, and incorporating the suggestion about better field names.
Looks good to me. A short comment or two explaining the reason for the fields of the MetaButtonSpace struct in src/theme.h couldn't hurt. Thanks!
Okay, done and done. Thanks! -> FIXED