GNOME Bugzilla – Bug 83129
Implement button layout preference
Last modified: 2004-12-22 21:47:04 UTC
Please consider adding a them which has the close button to the left and the minimize/maximize button to the right of the titlebar. Or perhaps just add some space between minimize/maximize and close, so as to reduce the risk of clicking close when one meant maximize.
Havoc: it was the thought of some of us in IRC that this could just be a theme property; no preference addition/confusion necessary- if you want a different layout, get a different theme. Just a thought, though.
This is a pref rather than a theme thing because changing themes shouldn't cause weird UI disruption, just harmless aesthetic change, IMO. Plus you shouldn't have to hack themes if you want the other button order.
Created attachment 9193 [details] A partial (unpolished) patch, see README for further details.
The patch has to allow themes to draw buttons according to either or both of position or function. This means essentially having 6 button positions (left-left, left-middle, left-right, right-left, right-middle, right-right), and the button functions, available to be drawn in the theme file, and also each of the button _functions_ available as a piece to draw. For the button layout I think a string with a list of written-out functions would be nice and clear: "maximize,close:minimize" This should be a gconf setting in prefs.[hc], not an environment variable.
It's supposed to be theme independent right? I've never looked at the theme-files but I was under the impression that they had noting to do with where buttons were placed, am I wrong? Why have fixed positions like left-left and so on? My patch let's you place any number of buttons, in any position, to the left or to the right, exactly once. The possible positions you've picked is but a small subset of all possible combinations. It works like this: Start from the left. place the first button, add extra spacing if any. Repeat this until the separator comes, then jump to the right and repeat the same procedure placing button from right-to-left. Finally put the title in what space is left between. It's simple, flexible and extensible. New buttons won't generate new positions. The environment variable was never intended as a final solution, it's notin' but a temporary fix in order to test out the patch.
The point about the six positions is that themes need to be able to draw buttons differently in those six. For "middle" buttons there may be more than one such button, this does not impose limitations on which buttons you can have where. Theme format has to be extended to support drawing the position-sensitive parts of the button and the function-sensitive parts separately.
FWIW I like louie's theming idea. It allows theme authors very precise control over the ordering so they get the intended effect they are after (eg. an aqua theme should probably always use the aqua button ordering since this is what users of such a theme expect, similar for a windows theme). An added bonus is that we don't need to add a "fix the broken button ordering" preference.
You avoid a "fix the button ordering" pref but get "break the button ordering" side effects from changing theme.
*** Bug 86084 has been marked as a duplicate of this bug. ***
Ah well... Do you really think that providing a broken default and providing configurability to unbreak it is the right thing to do? If you don't want to confuse those who dualboot into Windows, why not do some visual separation instead? The minimize and maximize buttons could be shown a bit farther to the left (and themes should render them somewhat different). You can see my experimental theme for an example: http://62.26.209.204/download/amadeus/Amadeus-Screen.png Actually the spacer is no real spacer as this doesn't seem possible right now, the spacer still belongs to the maximize button. But it shows what I mean. While this wouldn't completely fix the danger of accidently hitting the close button, it would definetly make it a lot harder. And it would have the following advantages: - No further preferences needed, no cluttered preference dialogs. - Themes wouldn't need to provide completely flexible button positions as those still would be hardcoded. So theming would be easier and more flexible. - Having all buttons at one place has definetly some usability and visual advantages. - A sane default which is still easy to understand for Windows users. - Less code, less bugs. ;) Could be done in a very short time (just needs some spacing between close button and other buttons and a way to theme this place). But this of course, is just a humble suggestion.
*** Bug 93972 has been marked as a duplicate of this bug. ***
Created attachment 11396 [details] [review] Patch, minus actual gconf-reading code
*** Bug 100773 has been marked as a duplicate of this bug. ***
Oh, this is in CVS now. I should do a better job closing my bugs.