maybe instead of the maximized state, just a vert/horz/both "fill"
function, to take available space.

Erwann: wipro tells me you're looking at this one? Is there some
Official Sun reason, other than personal interest on your part? In my
own humble judgement, this seems like a very minor enhancement...

The "Official" reason is that it could be considered as a regression.
The other reason is that people here at Sun -love- this feature ;)

Don't use this regression BS to justify lame-ass features now. ;-)

Yeah, really... if Sun is measuring regressions against Sawfish...
they ought to be going with Sawfish :) That said, in some cases this
can be useful and I'd argue (havoc) that if the UI is well
hidden/simple, and the code is clean, it would be nice to have in.

Created attachment 9066 [details] [review]
It's a complete implementation of the new feature.

I am not much in favor of having buttons change behavior based on 
which mouse button you click them with. I would rather do this as a
keybinding only.

I'd also sort of like to have just "resize to fill horizontally" 
instead of a separate state.

If it is a separate state, we would need to handle the _NET_WM_STATE
hints for that. 

But I don't really like it as a separate state, it adds too much
complexity.

Created attachment 9128 [details] [review]
A new version of my old patch. Cleaner code, but still the "sawfish-button-interface" to it.

Created attachment 9310 [details] [review]
Horrible hack to do vertical maximize

Attachment above was created before I knew this bug was open. It's
probably not very nice code, but seems to work, and uses a
keybinding. I think I could live with metacity if this functionality
was officially added...

*** Bug 87791 has been marked as a duplicate of this bug. ***

Any hope to get this implemented? Just as a keybinding option?

In previous versions of RH, clicking the maximize button with the
middle mouse button would expand the gnome-terminal to the maximum
number of lines while leaving the number of columns unchanged.

This was good and godly behavior.

In RH 8.0, this no longer works.

Is *nothing* scared?

Including my vote that this a good and worthy bug. To address the
recent  metacity "feature-crack" yardstick:

 - why do you want the different behavior

Because it's very useful to vertically maximize windows, as we read
top to bottom, and monitors aren't square, so horzontal realestate is
"cheaper" than vertical. Horizontal maximizing is no where near as big
of a deal for the above reasons, but is a nice "equiv" feature.

 - why would someone _not_ want the different behavior

It makes the behavior of the maximize button confusing. That being
said, most people will never know better, and those who do will
rapidly figure it out, as the behavior is very regular (different
mouse buttons mean different actions, a not-unexpected behaviour for
the system).

 - if _everyone_ wants the different behavior, we should just switch
   to it, not make it an option. Does everyone want it? Why or why
   not?

Everyone does, given the highly limited subset of questions. I don't
know anyone who maximizes a window with the middle/right buttons who
would be annoyed with this.

 - if there are two different behaviors needed, can the two cases be
   autodetected? if so let's do that, no need to make the user
   configure it manually.

There are, and they can.

 - is the reason for wanting or not wanting a minor issue that doesn't
   matter much? if so, then we should just pick a default, it's not
   worth a preference.

We should indeed pick a "default", one that includes vertical and
horizontal maximizing.

---

Okay, that wasn't the most useful of exercises, but I hope the point
is made. :)

Another option might be to scrap the old CUE minimize/maximize/restore
model and see if the Mac model works any better
(minimize/size1/size2).    

Apps are then only 'maximized' when you click the Toggle button (which
replaces the Maximize button) if it's the kind of app for which
maximization is truly useful, and other apps can request more useful
behaviours, e.g. a terminal might (by default) toggle between 80x40
and being vertically-maximized.  The user can also change the
size/position of the window in either of its toggled states, which
stops people complaining about not being able to resize windows when
they're maximized :)

*** Bug 97696 has been marked as a duplicate of this bug. ***

*** Bug 96587 has been marked as a duplicate of this bug. ***

Just another vote to add a vertical maximize function.  This is
extremely useful and not at all confusing when added.

Very true. Beginners tend to use only left mouse button for clicking
on active widgets, so it won't confuse them. More experienced users
don't get confused by other action on other mouse button - it is quite
common . Is there a problem with intergrating sort of above patches?
They didn't look very complex...

*** Bug 100082 has been marked as a duplicate of this bug. ***

Keybinding is in CVS now. Though I'm glad I didn't read this 
bug first, or I'd have gotten annoyed about all the <aol>yeah me
too</aol> comments and not been motivated to do it. ;-)

I'm not doing the "click maximize button with a different mouse
button" binding for now, because I can't even think of another example
where 
you click a button with a different mouse button and it does something 
different. Just too strange. Discuss on usability@gnome.org please,
don't reopen this bug for that issue.