GNOME Bugzilla – Bug 300210
Extra double-click on titlebar possibilities--"minimize" and "none"
Last modified: 2007-03-09 16:59:42 UTC
Could the following value be added to the '/apps/metacity/general/action_double_click_titlebar'-entry in gconf: "toggle_minimize" That value should set the titlbar doubleclick action similair to that in OSX and in BeOS: when you doubleclick the titlbar of a window, the window minimizes. I believe more people would prefer this feature. Personally, I never understood the usefullness of maximizing a window thru doubleclicking.
<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+