Who cares about the justification. The major problem with it is that the behaviour is unpredictable. You have no idea what is going to happen when you push that button for a given app. In some apps, they'll go full screen. A browser might resize to fit the current web page. iTunes actually shrinks down to a mini control window.
So now in order to use this button if a useful manner the user has to remember exactly what it does for any given application.
i tend not to use it for this very reason. i've wished, on more than one occasion, that a user could customize this action to be a "maximize vertically", as one could in gnome2. maybe i'm one of the few who actually used this, as it seems to have been phased out in gnome3. but i found it very useful.
Yeah, over the years Mac OS has increasingly offered functionality that was once a separate utility to install, MacDivvy is one of the few utilities left I install separately.
One of Divvy's coolest features is you can build preset window positions and attach them to keyboard chords. So for me, cmd-shift-space brings up divvy then hitting 1 makes the app fill the window, 2 is upper left 2/3 of the screen, 3 is upper right 2/3 of the screen, etc -- I have 7 or 8 presets. Full keyboard control of window position is awesome. It's the best $13 I've ever spent.
retailmenot also claims a $20% code, so that will knock some money off. But I happily paid retail and I use it 100 times a day. It's also particularly helpful if you use an external monitor at your desk and regularly resize windows as you attach or detach the monitor.
You're not the only one to use vertical maximization. I really liked being able to middle-click the maximize button for vertical, or right-click for horizontal. It seems that's no longer the case in Gnome-3-hacked-to-look-like-Gnome-2-in-Ubuntu-11.10. I suppose it's replaced by Windows 7-style border dragging, but that's less flexible as you can only do maximize, left half, or right half.
Windows 7 actually supports explicit vertical maximization; dragging the top of a window to the top of the screen will maximize the app vertically but leave its width unchanged.
I've got that action keybound to alt-space on my desktop.
Which would be WindowMaker.
Key benefits: virtually no development, Steve Jobs designed it, but for engineers on UNIX (well, NeXT), not idiots, and it's ~20 years old, so it's balazzzzzingly fucking fast on modern HW.
Stays the fuck out of my face, lets me get shit done.
When I first saw a fully customized WindowMaker in 2002, I thought, "Wow, HollywoodOS does exist!" Back when Linux used to come with several functional desktops, AfterStep and WindowMaker (both clones of NeXTStep) were my favorite, followed by Enlightenment (the only place I've ever seen window buttons on the side of the window).
I've played with a lot of desktops. twm, fvwm, fvwm2, WindowMaker, Enlightenment, icewm, various *boxes, GNOME and KDE through the ages, and XFCE4.
The latter is probably the closest to a replacement to WindowMaker that I've found, but it has two serious deficits:
1: No "raise on circulate" (with window contents visible) when you're alt-tab circulating through windows. Makes it really hard to find what you're looking for.
2: No pinnable window list. In WindowMaker, any arbitrary menu (or sub-menu) may be pinned to the root window. F11 (or middle mouse on root) brings up a menu of all open windows (the windowlist), which can be navigated (arrow keys or mouse), and if pinned, stays persistent while you hunt down the particular window you're looking for. Very useful when needed.
I’m using Gnome 3.2 on Debian Sid and vertical/horizontal maximization is still there.
To define shorcuts: Go to Settings, Keyboard, Shortcuts, Windows, and set your shortcuts.
To change the behaviour of middle-clicking or right-clicking on the title bar, install gnome-tweak-took, run gnome-tweak-tool, and go to the Windows section.
Gnome shell on Ubuntu is really misleading. On Fedora the support for it is first class so it works wonderfully, out of the box, including features like this.
(I like Unity too, but it needs work on things like multiple monitor support)
because they've come from Windows where that is the behaviour. Much like using ctrl or cmd as a modifier - when you become accustomed to one, the other takes some getting used to.
I know a lot of people who are more familiar with Mac than Windows and still don't know what that button does and simply ignores it. Along with the other small oval button that's there in pre-Lion.
You would have a point there, except that the zoom button, as I believe it's called, behaves differently in different applications.
An example, in some browsers clicking zoom will zoom to the page width, however in iTunes clicking zoom shrinks you to the miniplayer.
The different behaviours are confusing and difficult to remember, and not only goes against user expectations but isn't user-configurable.
How is this an argument? If users expect a button to do a certain thing then that is what the button should do. Where the behavior was learned is irrelevant.
How is THAT an argument? Different users will obviously expect different things.
The green button in almost every case just resizes the window to the optimal size. Whereas the maximise button simply wastes most of your screen estate (which, bizarrely, many Windows users think is actually taking advantage of their large displays, whereas its really doing the opposite).
So now in order to use this button if a useful manner the user has to remember exactly what it does for any given application.