<rant>
I've never understood the usefulness of maximizing a window by doubleclicking on
the titlebar either; I have only ever done that on accident (well, maybe a time
or two when trying to duplicate a very specific bug report).  It then always
requires an annoying effort to return things to normal.  However, minimizing
would be even worse for me.  What I'd really like is an option to turn all those
stupidly annoying double-click-on-titlebar actions off.  I.e. a
double-click-on-titlebar action of "None" (I have patches for this somewhere).  ;-)
</rant>

Other relevant comments:
http://mail.gnome.org/archives/desktop-devel-list/2005-April/msg00079.html

Now, the real question is, are either of these options ("minimize", "none")
worth implementing?  I believe we already have the right default, so the
question is do we gain enough edge case users (like you and me) to justify any
relevant increase in complexity?  I don't know the answer to that.

Depends on how you look at it. I'm no coder, so I have no idea how difficult
this is to code, or how much work it would be. Let's assume it's not a noticable
amount of work, for the sake of argument, then what complexity would be added by
adding the value as an option inside Gconf?

If it were to become an option editable somewhere inside gnome-control-center,
then yes, it would add complexity to Gnome. However, when an option like this is
added deep into Gconf-- then how does it add to complexity? Anyone willing to
burry that deep into Gconf probably already knows what he's doing anyway.

You could use the positioning of titlebar buttons (close, minimize, maximize) as
an example. This can also be edited via Gconf; which is the first thing I do on
any Gnome/KDE (however rare the latter is) install: I move the "close" ('X')
button to the left side. Hey, can't blame me for being a BeOS fanboy ;). But
anyway: don't you agree with me that modifying titlebar arrangement is just as a
complex option as setting titlebar behaviour?

Now, is this something you'd put into a release announcement next to "improved
stability" and "improved speed"? Definitely not. Will this bring a substantial
amount of new users? No, I don't think it will. On the other hand, however: will
it *alienate* users? Will it *confuse* users? I don't believe so.

The implementation of the feature would be trivial.

I agree the interface complexity would be none or small, and as Rob pointed out
the implementation would be trivial.  The main things I'm worried about are
testing (since testing can be exponential in the number of options, all options
must be of sufficient benefit) and the remote assistance case (e.g. "tech
support", see http://tinyurl.com/4uvs2).  The latter case has the possiblity to
cause confusion for users; it's probably not a big worry but as Rob pointed out,
we're not talking about a feature that is going to help many people either.

*shrug*

Well, I said all I could say... Descision up to you devs now. Can't force y'all
now can I :P

 - the main reason doubleclick titlebar does anything is that windows 
   users expect maximize (this is a fairly common request from them) 
   and old Sawfish users expect shade

 - we can't add additional enum values to a gconf setting because 
   it breaks old versions sharing the same homedir... so the 
   gconf key needs renaming basically

on the feature itself, I'm sort of ambivalent. I think the default should be
maximize though for Windows consistency.

> on the feature itself, I'm sort of ambivalent. I think the default should be
> maximize though for Windows consistency.

I agree on that one.

Just putting in my vote for adding toggle_minimize & toggle_none.

Created attachment 51328 [details] [review]
double_click_titlebar_minimize.patch

I couldn't stand missing this feature and I've created this patch (for metacity
2.10.3)

And as a suggestion, sending to back (aka lowering) of the window might be
another usefull setting for double clicking the toolbar.

Please note this is a quick and dirty hack.

I'd like to see that minimization via doubleclick on the titlebar is available
as an option also. This is especially useful as I when I use a OS X and a Linux
machine at the same time (for example synergy) then having configured both
machines to behave as identical as possible is a big big plus. 

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

Hello.  Reporter of the recent dupe here :)

I don't see why you can't have the same set of window operations in each place
(menu, doubleclick-titlebar, and the titlebar buttons).  I mean build each thing
from the same data.  This should improve metacity maintainability; when a new
operation is added, then it is then available in all three places.

The default for doubleclick could be "None".

There are a couple of reasons it's hard to do arbitrary bindings to arbitrary
mouse actions.

The first is that there are various special-case hacks to get exactly the right
behaviors in the different cases. Previous WMs that had arbitrary bindings
usually just got these details wrong. If you try to write the arbitrary-bindings
patch you'll find all these hacks and discover they are tricky to preserve while
keeping arbitrary configuration. (There's a patch in bugzilla somewhere I wrote
where I tried to do arbitrary bindings and just kind of gave up, too complicated.)

If you want to get a sense of this, read the code for
meta_frames_button_press_event(). If arbitrary bindings were going to be simple
to implement, then that code would be a 10-line function that just invoked an
action. But it isn't, it's a long function with a bunch of special cases. Also
the release event handler does stuff, and in theory the gconf settings can
change between press and release. And then there's another button press handler
outside frames.c for frameless windows, and some stuff in the keybindings code too.

The second reason not to have arbitrary bindings is that it makes the
configuration UI suck a lot more, though I think if we ever sanitized the
control panels in GNOME and had a UNIX Classic Users section this wouldn't be an
issue since we could just dump all the craziness over into that section.

Well, I don't know about technical problems, but as a user, I would like to have this option. Currently the old Unix people and Windows users get their habitual way, but Mac users don't.

(In reply to comment #6)
>  - we can't add additional enum values to a gconf setting because 
>    it breaks old versions sharing the same homedir... so the 
>    gconf key needs renaming basically

I don't understand why that's necessary; further, my testing seems to confirm that it is not.  Am I missing something in my reading and testing of the code?  We have a default hardcoded in to prefs.c (action_double_click_titlebar is a static var defined and initialized near the top of prefs.c) and prefs.c:update_action_double_click_titlebar() is comprised of the following code:

  MetaActionDoubleClickTitlebar old_action = action_double_click_titlebar;
  
  if (value != NULL)
    {
      action_double_click_titlebar = action_double_click_titlebar_from_string (value);

      if (action_double_click_titlebar == META_ACTION_DOUBLE_CLICK_TITLEBAR_LAST)
        {
          action_double_click_titlebar = old_action;
          meta_warning (_("GConf key '%s' is set to an invalid value\n"),
                        KEY_ACTION_DOUBLE_CLICK_TITLEBAR);
        }
    }

  return (old_action != action_double_click_titlebar);

Doesn't that mean it has sane defaults and even deals with completely broken keys?  I tested with giving it a bad string and also totally breaking the key by claiming it was an int instead of a string and metacity seemed to work just fine even if I restarted...

Created attachment 57081 [details] [review]
Add both "minimize" and "none" options

This is basically just a trivial change of Dick's patch to also handle the case of 'none', so he can still get the credit.  I didn't bother with trying to handle using a different gconf key because of the stuff I pointed out in comment 15; if Havoc can point out something I missed then we'll have to deal with that.

Well, ist seems some people are as "upset" as me ;-)
Macos X users are quite used to "double clik mimimizes"
as this is the fastes way to get rid of an unneeded window.
(no freakin' litte button needs to be pointed at)
But not having this feature is not as bad as the shade/maximize behaviour
shade ist my curent seting, as you could simply undo this by another 
doubleclick, maximize is worse as you have to relocate your titlebar :-(

I would sugest to add "none" and "minimize" do the list of
actions. (to make every user happy)

                      or

Remove the doubleclik handling alltogeter 
(to make it easy to get rid of it)

Created attachment 57802 [details] [review]
Forgot to update the schemas in the last patch; this one does that but is otherwise the same

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

Should have searched harder before making my own dupe of this issue. Sorry!

""
There is an option in recent versions of Metacity to have double-click do
minimize, settable via
  gconftool-2 --set /apps/metacity/general/action_double_click_titlebar \
    --type string minimize
""

How "recent" a version do you mean? Running metacity-2.13.34 from Fedora Core 5
Test 2, with action_double_click_titlebar = "minimize" (instead of the default
"toggle_maximize"), windows still maximize when double-clicked.

Could this be a FC-specific issue?

You need 2.13.55.

Using 2.13.55 now. It's very nice to finally have this option! I have been wanting it for a few years now. Thanks guys.

Any chance we can see this option being part of the window manager  gnome preference panel? It does not make sense to have there "maximize" and "rollup" and yet rely on the users to find this bug report to be able to get it to "minimize" instead. Especially new Linux users who come from the Mac world are really hungry for this option. So, please add it to the gnome wm dialog too.

I concur with Eugenia. It does not make any sense to have the GUI front-end drop down menu show only two of the three (top of my head) possible options, while in gconf they're all there.

to add this to the dialog, there should be an open bug against control-center, rather than comments on a closed bug against metacity ;-)

I bet the bug is already open against control center but am too lazy to search...

Strangely enough, there doesn't seem to be anything filed...

http://bugzilla.gnome.org/buglist.cgi?query=component%3A%22Window+preferences%22+product%3Acontrol-center+