Making the window controls go back where they belong in Ubuntu

Spread the love

In the latest version of Ubuntu, the development community decided that they needed to look more like a Mac, so they randomly decided to move the window controls (to close, maximize, minimize etc.) a window, to the left (incorrect) side of the window rather than the right (correct) side of the window.

In order to fix this “feature” here’s what you do.

Run gconf-editor (enter that phrase into a terminal). Find apps, then metacity, then general, then within that find “button_layout”. Double click on that.

It will say “close,minimize,maximize:menu”

Change that to “menu:minimize,maximize,close” and click OK. Instantly, you will be fixed.

Have you read the breakthrough novel of the year? When you are done with that, try:

In Search of Sungudogo by Greg Laden, now in Kindle or Paperback
*Please note:
Links to books and other items on this page and elsewhere on Greg Ladens' blog may send you to Amazon, where I am a registered affiliate. As an Amazon Associate I earn from qualifying purchases, which helps to fund this site.

Spread the love

25 thoughts on “Making the window controls go back where they belong in Ubuntu

  1. It’s the other way round – you need to make it “menu:minimize,maximize,close” for the close button to appear on the right side.

    And, AFAIK, the decision to make it more “Mac-like” was not made in the development community, but higher up…

  2. BTW: Science blogs is still infested with xxxxxx.co.cc disease. It just popped on this page. It has been on Ed’s and PZ’s as well.

    Cocos (Keeling) Islands ?

  3. I must be some sort of heretic. I like the new button locations. But I also keep my application bar on the (gasp!) bottom and my task bar on the top.

  4. DuWayne, is there a place you click to make the window controls for any given style move to the other side? I’ve not seen that.

    ZooGuard: What is the paper trail on who decided what? I’ve not seen that as well. I had heard it was the development community but I have no specific evidence in that regard one way or another, now that I think about it.

  5. @BruceH: One reason why many people (me included) consider the right side the “correct” side is because the close button on a maximized will be “infinitely deep”. You can move your mouse cursor to the top right of the screen, and then keep moving it in that direction, and you’re still over the close button. Effectively it becomes a giant, easy-to-click button.

    When the buttons are on the left, the close button isn’t quite in the corner, so it’s not nearly as easy to find and click.

    Since I tend to keep my hands on the keyboard all the time it’s not a big deal for me either way. 😛

  6. I prefer “close:minimize,maximize”, but I’m weird like that. If I need the window menu I just hit Alt-space. Actually, I rarely use any of the buttons– Alt-space followed by {n,x,c} is a lot easier.

  7. Damnit – I wish I had a little flashing light that would tell me when I am using the Cyrillic layout.

    Sorry, I skipped a step in there. Goto system->preferences->appearance and the “them” window should open up. The first option is the current default, the second option and as far as I can tell most of the options put the controls to the right. I believe you can even keep the circular buttons, but set to the right rather than the left.

    This sort of thing is why I am able to comfortably use Ubuntu now. Most of this sort of shit is easy to deal with without the use of a terminal and at this point actually easier to deal with than navigating the menus in Windows. That is not to say that I don’t see the utility or, for that matter, appreciate the utility of command lines. It’s just that for simple shit like changing the appearance I prefer a menu – preferably a right click menu.

    Yes, it’s lazy and teaches me shit about the language, but I will make up for my deficiencies by ensuring that my children learn that language.

    Now, for my next dose of irony, (not to mention the blind leading the blind) I will go teach my mother how to use MS office.

  8. Hmm. My Ubuntu installs were fresh as three weeks ago and I installed updates yesterday. I switched mine to the second choice on that list shortly after I last installed Ubuntu and they are all still to the right. I even just tried switching them back to the default and back to the right without any problems. I just went through teh list and all but the default theme and “radiance” set the controls to the right.

    Very interesting. I will check it out on my desktop when I get a chance. I left that on the default setting, because I mostly just use it as a makeshift server.

  9. At least it is configurable. Unlike the look-alikes, Windows and OS X. Both of which I use constantly, switching between them on a minute by minute basis, with the same mouse no less (OS X + RDP to my Windoze box). Which just goes to show you can get used to anything, if you have to do it often enough.

    Gnome? Is anybody working on a Gremlin desktop manager? It would randomly shuffle your preferences for you every time you reboot.

  10. skeeto:

    “Infinitely deep” is why the Mac developers put the menu bar at the top. I actually had to think about that for a second but I’m guessing putting it on the right was a Steve thing — with no menu bar at the top of the screen on NextStep, it actually did make sense to put it there, where it still makes sense on KDE, Windows, and Xfce. I don’t know if this necessarily applies on Gnome though — Gnome’s rather schizoid (mis)use of the menu bar makes the rationale for button placement moot.

    Curious… I’d never given the top-right closebox a moment of thought before… just figured Next did it so they wouldn’t get sued by Apple…

  11. Claiming that these controls’ “correct” position is on the right is a religious claim that cannot be backed by evidence.

    Regarding Fitts law, putting the close box at the far left works just as well as at the far right. But if you are really serious about Fitts law, then you despise menu bars inside windows.

    Also, maximizing to the full screen is also a highly questionable choice. Maximizing to the largest area necessary to enclose all the available window content arguably is more efficient use of available screen real estate.

  12. Ah, excuse me… the menu bar has to have its controls on the same side as the vert. scroll bar, yes?

    I always wondered why by default, the gui version of emacs put the scroll bar on the left (though as expected this is easily changed).

  13. But if you are really serious about Fitts law, then you despise menu bars inside windows.

    Why?

    Maximizing to the largest area necessary to enclose all the available window content arguably is more efficient use of available screen real estate.

    That does not make sense for a lot of applications. More than half of what I do is done inside a text editor that starts out blank. 20 percent of what I do is done in a terminal that starts out with a prompt. There is no pre-existing thing. Rather, there is my personal concept of what size I want the window to be when I use it. And, I do wish that was a bit more automatically adjustable.

  14. Why?

    Because a menu bar inside a window has a finite height, which makes it a hard target to hit. While a menu bar at the top of the screen has an infinite height, and makes it easy to hit.

    On my Linux-Gnome screen, the top of the screen is occupied by system menus. Application menus are in their own windows. The result is that the most often used menus are difficult to hit, while those menus that I use less often use the most precious User Interface resource: the screen edge.

    This is totally screwed.

    (regarding your comment re the maximizing behavior, you basically have the same opinion as mine: always maximizing to the whole screen is dumb).

  15. Always maximizing to the whole screen is the behavior I want on my laptop. On my desktop, I would like certain apps to always maximize to a particular monitor’s screen, other apps to do different things, but always maximizing is not good on that computer (and since there are multiple heads, “maximizing” is not “maximizing” unless X is broken.)

    Now I get what you mean about the infinite height. Makes sense, except it is also the case that the menu is not always nearby. Unless one always maximizes the window. Therein lies the problem. .

  16. Maximizing: our opinions differ somewhat after all! To use you own examples, I certainly don’t want a terminal (or a text editor window) to maximize to the full width of my 2560 pixel desktop screen (nor on my 1920 pixel laptop screen for that matter).

    Fitts law states that the time acquire a screen target depends both on the target size and on the target distance:

    t â?? f(d/s) where t is the time, s is the target size, d is the target distance, and f is an increasing function, often taken to be a log function.

    As you can imagine, when s â?? â??, then d doesn’t matter.

    The point is: for the top of the screen (or any edge), distance doesn’t matter.

  17. Which fits with the accelerating behavior of mice: a flick of the wrist and your mouse pointer is at the edge, whatever the distance from its starting point.

  18. I certainly don’t want a terminal (or a text editor window) to maximize to the full width of my 2560 pixel desktop screen (nor on my 1920 pixel laptop screen for that matter).

    If I had a really wide screen, I wouldn’t want that either. I prefer multiple regular shaped screens.

    I don’t have any problem getting my mouse to hit a target, though. And, Fitts law is about time to hit target, while my concern is knowing where the target is because I’m accustom to it. I may, for instance, have preferred the windows controls on the right side (or even bottom somewhere like they are in emacs) had I been accustom to that.

    I think this may be a case of misplaced fetishizing of an efficiency that is not really important. The best use of the mouse, if you want efficiency, is to hold down your papers in a breeze while you get busy with your keyboard!

  19. Finding where the item is is part of the acquisition time. Most -if not all- of that part, can be reduced through learning (familiarity). The rest of time obeys Fitts law, even if your consider it trivial.

    Of course, if you don’t use the menu bar, then its position doesn’t matter much.

    Common user testing shows that most users use it quite a bit too, even when keyboard navigation is available, except for a very few commonly used commands. Your profile is almost certainly different from Joe User’s.

    Now you may argue that Linux is not intended for “common users”, and therefore my point do not apply. I have no problem with that.

    And which papers? All my papers are scanned and stored. Thereafter they occupy some real estate in a window on my screen, why I want maximized to the paper size, not more.

    Having such a large screen (two of them in fact) lets me have many pieces of information on the screen at the same time, which I find invaluable for my job developing software. The last thing I want from my IDE is to cover all those windows when I maximize one of them.

  20. Greg:

    I suspect menu bar placement on very large screens is largely a matter of personal choice. I won’t speak for all Mac users, but setting the mouse speed as fast as I can reasonably handle it works fine for me. It may be different for multiscreen setups, but I’ve never been so lucky as to have that.

  21. Also, re Emacs scrollbar behavior:

    I don’t know the exact history, but iirc the Athena widgets were developed at a time when the GUI vocabulary was still in flux. Personally I find manipulating Athena widgets to be pointlessly complicated anyway – grab and drag with the index finger maps much more closely to meatspace object handling than Athena’s strange middle button thing.

    I do wonder how closely Athena behavior matches Smalltalk-80’s. Squeak isn’t as obvious a parallel as you’d think, though it’s pretty alien in its own right.

Leave a Reply

Your email address will not be published. Required fields are marked *