Weird, windows XP indeed does this. Who knew. This makes _no_ sense to
me, but if a lot of people use it I guess it's harmless to implement.

I've double clicked the menu button by accident and closed my windows.
This seems like truly bizarre un-obvious behavior. Not only that, but
I seriously thought my program had -crashed-...it took me at least 5
minutes to figure out what I'd done.

Windows 3.1 did not have a [X] close button on the titlebar. AFAIK,
this is still implemented in Windows only for backwards compatibility.
I consider this poor UI practice.

<two_cents>
I'm with Kenny; overloading the button like this seems like a recipe
for accidental closures and the like.
</two_cents>
I've cc'd usability for their Professional Opinion. :) 

It's true, most of the 'big' window managers have tradtionally
implemented the "double-click on menu button to close" behaviour-- CDE
does it too, and so does 4dwm, the IRIX window manager.

However, those window managers don't have an explicit close button on
their title bar either, and I have to say I've never missed (or even
looked for) this behaviour since I switched to sawfish/metacity for
that reason.  I vote to leave it as it is too.

fwiw i agree with louie and calum, This i just plain dangerous. Since
it is not at all obvious to the user that double clicking here will
close the window. (ie. metacity gives not visual clue that this will
happen) WE don't want to make closing windows accidentally this easy.

A counter-example is the OS/2 Warp 4 workplace shell, which has both
an explicit close button and double-click close behaviour.

Frankly I find it difficult to understand why so many people are
opposed to such a non-obtrusive feature that, as pointed out, is
implemented in just about all windowing environments that have been in
use for the last decades. 

As for this being "dangerous": are there any known cases of icewm, CDE
or KDE1.x users who ended up in hospital because of inadvertently
closing their windows? ;)

Reinout: I don't think the argument that everyone else does this so we
should too is a good reason to implement a feature.  I don't think we
should be bound to other people's mistakes simply because others have
chosen them as well. We should be trying to design a good ui.

Personally i find this confusing, there is no clear visual indication
in the ui that double clicking here will close the window. It is 
dangerous in the sense that closing a window is always a dangerous
operation. One of the main complaints about the current window's
button ordering is that it is too easy to accidentally close a window
when trying to maximize a window.(this applies to metacity as well,
but i'm not trying to start a discussion about this issue here, I'm
only using it as an example.) I think this applies even more to this
feature. Personally I would be really really confused if for some
reason i accidentally double clicked the upper left corner only to
realize that my window went away.

  I don't think the argument that everyone else does this so we
  should too is a good reason to implement a feature. ... We should be   
  trying to design a good ui.

In principle I agree 110%. This argument was no use in the "should we
have an extra close button on instant-apply windows"-debate, however. 

I don't want to make this a bigger issue than it is, but let me restate:

* The people who are used to this behaviour will sorely miss it in
metacity;

* The people who are not used to this behaviour suffer no disadvantage
because 1) The window-close command isn't unconditional; when there's
unsaved data the program gets the opportunity to pop up a warning
dialog and 2) it doesn't involve any visual change in the GUI.

The visual indication argument is weak: what is the visual indication
that double-clicking the titlebar maximizes a window? (Or doesn't
metacity implement that either?! can't check right now.)

The window I closed by accident was a web browser window. These do not
require confirmation, but finding the site (remembering the search
terms you entered in google half an hour ago) can be a big hassle.
Accidental closing is a pain. Even if a little pain, it's still a pain.

Conversely, closing windows is not evil. I do it all the time, so it
shouldn't be hard. Window Managers which make it hard (no [X] button)
are simply unusable. And it shouldn't always ask for confirmation. I
usually mean it. When using a button order which places [X] near the
other buttons, I tend to mean it less often. When double clicking a
menu button closes it, I mean it even less often. By making buttons do
only one action, you have less accidents. 

Reinout mentioned that there's no visual indication of double clicking
the titlebar causes it to maximize. FYI, in Metacity, Window Maker,
and Sawfish (by default), double clicking shades the window, i.e.
"draws the window into the titlebar." MacOS < X did this originally,
IIRC. While not a lot of indication, it isn't a critical feature, and
since it is drawing the window up into the titlebar - usually with
animation - it seems a logical choice. The first time you do this, you
may wonder about it, but then it's pretty useful.

Also, I would like to mention that many environments (MacOS, OPENSTEP,
 ...) do not have a menu button at all, hence this question could not
even be raised with them. Nor is one really required, given right
click menus. However, I won't go further into button orders here, as
that is a separate (yet related) issue.

I couldn't have said it better my self :)

In 1991ish and 2ish, the order of the menu options were different.

In Metacity, the window menu options are ordered:

Close
Minimize
[Un]Maximize
Shade
Move
Resize
------
Workspace controls

In Windows 3.x, Close was the last option.  The double-click behavior
was created for that reason.

cc'ing usability guys in case one of them wants to reopen, but there
have really been very few requests for this, which indicates to me 
that most people don't know that it's traditional behavior. 
And it clearly seems silly if you ignore tradition.

Also I'm not even sure how to implement it (e.g. keep the menu from
coming up on the first click of the double click).

I would vote for this bug (I very used to close windows by double
clicking the windows menu...) if I could...
My argument: Take it serious: It's faster if I'm in the left half of a
window mith the mouse pointer :)
Really, this may sound rather silly, but if I have to go to the upper
right corner to close a window (or close it by pressing alt/f4,
admitted), it seems to be more unneccessary work imposed by metacity's
behaviour. And I'm sure there are other people who are not complaining
politely, they switch to kde and get a "gnome sucks" attitude.
IMHO, it should be at least configurable.

Another request for this feature from user: Jan Rathmann <JanRathmann t-online de>
http://mail.gnome.org/archives/usability/2006-March/msg00069.html

Might as well point out yet another reason why this is a really bad idea:
http://mail.gnome.org/archives/usability/2006-March/msg00088.html

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

I guess I'm not the only one that would've appreciated this feature.

http://bugzilla.gnome.org/show_bug.cgi?id=341123

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

Funnily enough, one of the Microsoft UI designers reflected this week on what happened when they tried to remove the double-click-to-close feature:

http://blogs.msdn.com/jensenh/archive/2006/06/08/621757.aspx

Created attachment 67516 [details] [review]
Make double-clicking the menu button close the window

Well, after I saw my boss actually close a window this way the other day, and after reading that Microsoft guy's comments, I thought I'd try and see how difficult it would be to fix this. It turns out it's not difficult at all. I've made it disabled by default so that people who aren't expecting it don't close their windows by mistake.

Thoughts? Calum? Anyone?

I guess it's just not clear to me that enough people really need (rather than want) this feature. From a usability POV I'd agree it's probably fairly harmless, especially if you have to explicitly enable it somehow (although it would be better if that weren't necessary), but my gut feeling is that it's generally not a great idea to add new code just to replicate a legacy feature on another platform.  But that part's up to the maintainer I guess :)

As per Calum's comments, let's leave the bug closed.  I think Thomas' patch is great, as it will allow us to point people to it if they are really adamant if they want it.  I'm assuming it'll be a small minority.  But if by chance it actually gets picked up and widely distributed and appears in most of the distros (which has happened in similar cases with other patches in the past, but is really unlikely and rare but is a great way of demonstrating that we perhaps made the wrong decision about a feature) then we can start having a discussion about whether we should reconsider whether to include it.

It would be really great if you just accepted Thomas' patch. As it can be disabled (or even must be enabled) by gconf, it doesn't hurt anyone, does it? And it could make maaaany users (like me :-) a little bit happier.

making it a config option is just nuts imo, either put it in or don't.

I do agree with elijah's assessment though.

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

For what it's worth, I'd love to see this implemented.  I switched from Windows to Gnome about 2 months ago, and I've been missing this feature badly ever since (so much that I was thinking about coding my own patch before I saw this bug report).

Adalbert, Adam: If you want this behaviour, you might also try to talk your distribution maintainers into adding the patch downstream. As Elijah said in comment 22, it's a little more likely to get approved upstream if that happens.

(In reply to comment #27)
> Adalbert, Adam: If you want this behaviour, you might also try to talk your
> distribution maintainers into adding the patch downstream. As Elijah said in
> comment 22, it's a little more likely to get approved upstream if that happens.

Done:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381509

I hope that if Debian will include the patch, it will automatically enter its derivates, which are pretty many. (Ubuntu, Knoppix, Kanotix, ...)

NOTES FOR DOWNSTREAM DISTROS (not sure if any of them will read this, but at least I can refer them to it if I find problems):

It's worth noting that if distros adopt the patch (obviously, against our recommendation considering that we're not adopting it), they should not do so without at very least first modifying the name of the gconf key.  Polluting the general namespace is bad practice; see bug 95273 comment 19 and bug 167781 comment 5 for more details.

Also worth noting, is just that as Havoc said in comment 24, having it be a pref is flat wrong (it's perfectly fine in terms of a patch made only for other people to play around with as Thomas did, but not for official inclusion).  Making it a pref won't be accepted regardless of what distros do.  The only possible sane option other than the current behavior of leaving it out entirely, would be to have it always be on.

I'm quite happy to rewrite the patch in those terms if anyone asks me to.

(I'm not personally advocating this patch getting in: I don't mind whether it does or not. I'm just, as Elijah said, making stuff for people to play around with.)

Created attachment 70345 [details] [review]
Patch adding appropriate GConf schema

Thomas asked me at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381509 to post the schema-patch here, so here it is.

Adalbert: Things have moved on since I said that: consensus here over the last day or so is that if this were ever to be included it shouldn't be as a gconf option, so the patch isn't needed any more.

Nobody has mentioned this, so I thought I would add that Windows uses a bold font in context menus to indicate the action double-clicking on the current object will have. Right-click on a file: "Open" is bold, right or left-click on the system menu icon (top-left): "Close" is bold.

I always thought this was a good idea but I presume it's not sufficiently intuitive for GNOME. I wonder if there's a double click symbol you could feature in the menu caption instead (or an animation or tooltip).

FWIW, there is a fairly standard double-click symbol (used by screencast tools etc. to show where the user has double-clicked on something), but I doubt its meaning would be obvious on a menu.  Apart from which, the GNOME HIG says that the first item on a context menu should correspond the double-click action, so that makes any indicator somewhat unnecessary anwyay.

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

Incidentally, if patch 67516 begins to rot and someone needs it, I'm quite willing to fix it up to work with trunk.

(In reply to comment #36)
> Incidentally, if patch 67516 [edit] begins to rot and someone needs it, I'm quite
> willing to fix it up to work with trunk.
> 

It doesn't apply on Metacity 2.20.0, building on Debian Lenny (using dpkg-buildpackage and placing the .patch under debian/patches), it worked in 2.18.x

Thanks; now on my to-do list, since I promised.

Is this patch still being maintained? I got the old patch to work with 2.22.0 from the ubuntu repos. Since I'll do the same for whatever version ships with 8.10 I could as well post those patches here if anybody is interested.

Sure, I'm interested-- post away.

Yes, if you already have a patch for 2.22.0 please post that (Fedora 9 ships this version).

I'm certainly interested as well. 

I realize that I am only one user but I also would appreciate having the ability.  I grew up post-Win 3.1 so you cannot blame the desire solely on old users.  It was within the last year that I adopted the double-click to close windows, but when I realized the availability of the feature the convenience was great enough that I now use it the majority of the time (it even works under Vista where there is no icon).  Personally, since its a double click I find myself less likely to accidentally activate it.  I spent a minimum of 35 minutes in the process searching through gconf, goggling for help, finding this bug and reading all posts.  Then additional time to registering and reply because I don't know how to install the patch, and if I did it sounds like there is no guarantee that it would work with my version of GNOME.  If there are any other users like me it would seem a lot simpler to allow the option to change the action somewhere in gconf.  I thought one of the pros of the Linux GUI was supposed to be customization.  My layout is custom and far from standard GNOME, or KDE for that matter, but both environments allowed me to set it how I wanted (granted it was a lot easier under KDE because I could do it all in the GUI).  There exist keys for "action_double_click_titlebar", "action_middle_click_titlebar", "action_right_click_titlebar".  Would it really be that harmful to have a key that controls the action on double click of whatever the upper left-hand corner is called?  As far as the concern about not showing the menu before the second click, on the Vista box I just tested on, windows does show the menu.

Created attachment 120237 [details] [review]
Double-click to close window (2.24-ish version)

As promised, here's a very belated current version.  The prefs code has been removed as Elijah requested.

If you can get two or even one distro downstream to include this patch, I'll seriously consider committing it here.  I imagine Ubuntu might be pretty interested.

Oh, thinko:  I checked that a guint wasn't -ve.  I'll fix in a bit.

Created attachment 120247 [details] [review]
Double-click to close window (2.24-ish version)

This uses a signed int.

Blog post:
http://blogs.gnome.org/metacity/2008/10/08/double-click-to-close/

In the comments, Leonardo Fontenelle makes the fair point that "a user might double-click the icon when they meant to single-click to get the menu" can be answered by "a user might click the close button when they meant to click the maximise button, since they're right next to one another".  However, at least it's obvious what's supposed to happen in that case.

(I suppose we could change the tooltip from "Window Menu" to "Window menu (double-click to close)").

(In reply to comment #47)
> In the comments, Leonardo Fontenelle makes the fair point that "a user might
> double-click the icon when they meant to single-click to get the menu" can be
> answered by "a user might click the close button when they meant to click the
> maximise button, since they're right next to one another".  However, at least
> it's obvious what's supposed to happen in that case.

Double click *is* a valid action on the largest area of the title bar (everywhere except the buttons), namely maximize or rollup, depending on how you configured it. Making double click perform a (possibly) destructive operation on the corner (the icon is in the corner), i.e. closing the window, while the remainder of the title bar performs a useful and non-destructive operation, is a *very bad idea* imnsho.

> (I suppose we could change the tooltip from "Window Menu" to "Window menu
> (double-click to close)").

For sanety's sake, please... no!

IMHO... Let's no panic here. If the user double-clicks by mistake on the left corner and if there's something worth saving in the window, a window will popup asking the user to save. It's not like people's files are going to be deleted because of that or if any work would be lost.

> Making double click perform a (possibly) destructive
operation on the corner (the icon is in the corner), i.e. closing the window,
while the remainder of the title bar performs a useful and non-destructive
operation, is a *very bad idea* imnsho.

Isn't that *exactly* what happens if you click on the other corner?

If you double-click on the title bar, what is the chance you accidentally do it on the icon?

I think you're exaggerating.

If you'll look at the windows that have an icon on the top left and then click on that icon 90% of he time a menu appears that has the close item preselected with a big fat X. It make perfect sense that if one click shows the menu then a double click should show the menu and select the preselected item with the big X (close). Ergo: the double click becomes a fast path to close the window. 

Now if the desire is to create a great UI, then why not add the function that will allow the end user to either enable or disable that double click action. A UI that allows me to control how it works is surly greater than a UI that works the way some developer, maintainer, or designer thinks it should work. 

Keith McFarland (reppeprd)  

(In reply to comment #51)
> why not add the function that will allow the end user to either enable

Because that would add two extra pieces of code, not just this one but the one to enable or disable it.  Then it would either be on by default or off by default.  Either way, especially if it was off by default, there would be extra code paths which were rarely run and where bugs would creep in.  People who want crazy levels of configurability (and adding things like this is precedent for a thousand more) are using Compiz. See http://ometer.com/features.html .

@Keith:

Forgot to say: I don't know what your distro is, but please go and convince them to include the patch.  When you've convinced them, I'll talk to you and the downstream maintainers and be a bit more convinced.

Do you think those maintainers have more knowledge about how the UI should behave then the Gnome developers themselves?

@Olaf:

Metacity is free software.  Havoc and Elijah and I get to decide what "should" happen in upstream Metacity.  The downstream maintainers and you and Keith and HM the Queen and everyone else on this planet get to decide what "should" happen to it once it leaves download.gnome.org.  That's the point of free software.

(In reply to comment #51)
> If you'll look at the windows that have an icon on the top left and then click
> on that icon 90% of he time a menu appears that has the close item preselected
> with a big fat X.

Eh, what do you mean by "preselected"? When I single click the icon on the top left of a window, a menu is shown without any item selected.

Created attachment 124290 [details] [review]
Full patch (prefs and schema patches included)

Just created a patch with additional code, which will allow to control this feature. :) Tested and working well on current Arch Linux, double-click-menu-to-close disabled by default, so typical users should not see any differences. Also added somewhat useful description to the schema to prevent turning this feature on without knowledge on it.
I can also provide translations to russian and ukrainian languages if needed.

> double-click-menu-to-close disabled by default

The next feature request will be to have it enabled by default. ;)
Inconsistencies like this between installations are very irritating.

Having this disabled by default is very close to the current metacity behaviour. Users who need this (like me) will enable it.
Treat this like a compositing manager feature, if you like. ;)

Thanks for the patch, but if you read further up you'll see that the optionality was in the original version (patch 67516) and it was taken out on Havoc's advice in comment 24.

I've read all the thread, but I don't follow, what's bad in having this as gconf option? Typical users won't notice it anyway and will work safe, old-school users will turn it on and have an ability to work more productive (e.g. no need to move mouse on my 1680x1050 from tor-left corner to top-right corner). And, as I've pointed before, there are already some options which are controlled by gconf key only and there's no harm on it, I think. :)

BTW, this feature was a reason that held me on Xfce for two years before I've switched to GNOME. :)

> Having this disabled by default is very close to the current metacity
behaviour.

What's the difference from the current behaviour?

The difference is that you can turn this feature on by clicking on a checkbox in gconf-editor.

Any change this will be ever accepted? :) Maybe it is needed to improve the patch somehow? Comment 24 was written more than two years ago, so, maybe, this no longer applies?..

I'm just in doubt that my distro will apply a patch that was rejected upstream.

How does one apply the patch in comment #57?

I need an easy way to do it, so that even beginners can do it. I am writing about Ubuntu for beginners, and I am sure many of my readers will want to have this function.

I understand that some Linux users may not want this feature, but try to look at the bigger picture. If you want to attract new users from the Windows World, the lack of the double click is a show stopper.

It is really annoying not to have the function if one is used to it from Windows (or in my case OS/2). And I fully understand comment #61 regarding the choice to stay away from Gnome because of this.

I think this is a very good example of programmer's wishes versus user's wishes, and why Linux is still having a hard time winning over Windows users. As long as the programmers choose functions from what they like themselves instead of what the users want, Linux will never be a mainstream OS.

[slightly reordered comments]

(In reply to comment #65)
> [...] I am sure many of my readers will want to have
> this function.
> [...]  If you want to attract new users from the Windows World,
> the lack of the double click is a show stopper.
> [...]As long as the programmers choose functions from what they like themselves
> instead of what the users want, Linux will never be a mainstream OS.

Your claims 'will want', 'showstopper' and 'what the users want' are not backed up at all. Do you have any usability testing results? Any reports? Anything?

> I think this is a very good example of programmer's wishes versus user's
> wishes, and why Linux is still having a hard time winning over Windows users.

My opinion is that this is just a matter of clean UI design. It has nothing to do with programmer's wishes. Metacity (and the rest of Gnome) have a clear UI design, and mimicking random (bad?) features from othe environments does not fit in this picture.

It would also help if you leave out nonsensical statements like the last one—it doesn't help your argument at all.

(In reply to comment #66)

No, I have no usability test. And it is not a question of usability, it is a question of habit.

It might be a clean UI design not having this function. And it might be best, if you started from scratch - even though it is easier to double click on the icon if the mouse pointer is on the left side of the screen. But you are not starting from scratch.

If people are using this function in Windows, they will surely miss it in Gnome. You will find several forum threads about the problem if you search in Google.

Besides, as I wrote in comment #65, I am writing about Ubuntu for beginners. It is my job to identify problems that users may encounter and then offer a solution. And I am usually quite good at spotting the problems new users need help with. The missing double click is not the biggest problem for new users from the Windows world, but in my opinion it is the most annoying.

Of course things will work differently in another OS, but with most things, it is things, that you think about. They are easier to get used to. The double click to close a window, you don't think about - until it dos not work. And even when you know that it does not work, you still click.

There is a reason why Microsoft has not removed this function.

I could understand the resistance from the Gnome developers, if the function would break something, but as I understand it, that is not the case. Especially if you choose to have an option to turn it on.

There are a number of users that have requested this feature. What do
you mean by "mimicking random (bad?) feature"?
Maybe the focus should be a bit more on a practical design then on an
ultra clean design.

What's the disadvantage of this feature?
Other than major design pollution. ;)

(In reply to comment #65)
> How does one apply the patch in comment #57?
> 
> I need an easy way to do it, so that even beginners can do it. I am writing
> about Ubuntu for beginners, and I am sure many of my readers will want to have
> this function.

http://blogs.gnome.org/metacity/2008/12/16/how-to-apply-a-patch-under-ubuntu/

In reply to comment #69

Thanks for the guide! 

In reply to comment #57
The patch does not seem to work in my Ubuntu 8.10. 

I have ticked off the setting in Gconf Editor: Apps => metacity => General =>  close_on_double_click_menu. Am I missing something?

(In reply to comment #70)

You must tick in on to be able to close windows this way.

I have said I'll reconsider the issue more seriously if

a) the UI people say it's a good idea
b) any major distro includes the patch
c) anyone seriously reads http://ometer.com/features.html and attempts to answer the questions therein.

I would like to see links where all you people trying to persuade us here are attempting to persuade your distro's maintainers.  (We have a link for Debian, and they rejected the idea on the same grounds that the GNOME UI people did. <http://ometer.com/features.html>)

I wrote the original patch for this: I myself double-click the menu button fairly regularly before remembering it doesn't work in GNOME.  So persuading *me* it's a good idea isn't much help, because I would already find it useful.  But I have my maintainer hat on, and my job as maintainer is to find a good balance for the most people, and that often means saying no to patches, even my own.

Sorry, that Debian bug report was
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=381509

Reply to comment #70

Sorry - I though that "ticked off" meant that the tick was there. In other words: I have turned the function on, but it does not work.

Reply to comment #71

a) Seems like a hard job to persuade them. If the fact, that the function does not break anything, and that it is opt in, and that users from the Windows world will miss the function and be annoyed if it is not there, don't persuade them, then I don't know what it takes.

b) As far as I understand from reading various forum posts about the problem, the distros will not include the function if it is not in Gnome. So persuading the Gnome maintainers by persuading the distro maintainers seems like a catch 22.

c) I will try to answer the questions in the paragraph "Important homework for any feature" as good as I can. But I am not a programmer, and I am new to Linux.

* The function has been in Windows since Windows 3.0 (as far as I remember), and Microsoft has decided to keep it, even after the introduction of the close button.

* There is an alternative: Closing the Windows by clicking the close button. The problem is, that people from the Windows world expect the possibility to double click on the menu button. And if you are used to close a window this way it is more like a reflex, and not that easy to unlearn. That means, that new users will have a hard time getting used to Linux - and they are constantly reminded, that they are in a foreign territory.

* The function has been rejected from an UI point of view. In my opinion, the users point of view is more important than a "clean UI" - especially as this function does not change anything for other users than the ones that wants it.

* I don't know if the function is present in custom vendor-specific patches.

* I don't know if there are any applicable standards - except that it is used in Windows and OS/2, and maybe other OS's as well. I guess that it is also in Xfce, according to comment #61.

* Performance-related, the function is a plus. It can save the user time when the mouse pointer is at the left of the screen. And for those that is used to the function from other OS's, it saves even more time, because they now are double clicking the menu button, getting annoyed, and then having to close by clicking the close button.

* As far as I know, the function does not interact with other functions. Some comments, like comment #2, has mentioned that you can close the window by accident. I think this is less of a problem than having the close button next to the minimize button. Some have mentioned loss of data in case of an accidental closing, but I think most, if not all, programs warns you if you are trying to close a program when having unsaved data. And again, I think this is less of a problem than accidentally closing instead of minimizing.

* I don't know of any mailing list threads.

* The UI team apparently does not like it.

* The function is entirely for the benefit of the users.

(In reply to comment #74)
> Sorry - I though that "ticked off" meant that the tick was there. In other
> words: I have turned the function on, but it does not work.

Did you try the version in attachment 120247 [details] [review]?

I just tried, using the same guide to install it but replacing the attachment number 124290 with 120247. After issuing:
wget -O - http://bugzilla.gnome.org/attachment.cgi?id=120247 | patch -p1

I get this error:
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: src/core/display.c
|===================================================================
|--- src/core/display.c	(revision 3944)
|+++ src/core/display.c	(working copy)
--------------------------
File to patch: 

Oh, try using -p0 instead of -p1.  Nuisance.

In reply to comment #77

Now I got this:

patching file src/core/display.c
Hunk #1 FAILED at 77.
Hunk #2 FAILED at 1778.
2 out of 2 hunks FAILED -- saving rejects to file src/core/display.c.rej

I continued with the rest of the steps, but it does not work. Do I have to restart the computer?

No, either it'll have installed a working version or nothing at all.  There's no need to restart.  This just means the patch is out of date now, so I need to rewrite it.

I find the arguments in comments 67 & 74 pretty compelling, and also Calum's comment 19.  As I think someone else posted, we have another utterly idiotic usability feature solely for reasons of "compatibility": double-click on titlebar to maximize (by default).  And that other feature is pretty closely related to this one, as both deal with double-clicking on window decorations.  There is something to be said for consistency...  ;-)

That said, I also found it pretty compelling that Calum could dig up so much history in favor of the feature (CDE, 4dwm, the IRIX window manager -- comment 4, and the notes on how Microsoft felt forced to leave it in -- comment 19), yet still voted against it (comment 4 and comment 21).  And Matthew spoke up against it too (see link in comment 15).  While no one provides perfect advice, Calum and Matthew have reliably provided pretty sound usability advice over the years; I probably trust those two more than most anyone else in this area.


So I could understand someone putting the feature in, based on the former arguments.  If it were up to me, I would defer to Calum and Matthew and leave the bug as is unless they changed their opinions.  But what I'd do isn't so relevant anymore...Thomas is doing nearly all the Metacity work these days, so the decision is entirely his.

(And I wouldn't consider this comment relevant enough to write if it weren't for Thomas' blog post.)

That makes me more inclined to commit it.  As I've said, I'm personally a fan of the feature, but in my maintainer role I still don't want to put it in against Calum's advice (though on the other hand it's true he said "it's up to the maintainer").

Incidentally, I think the argument that it can lead to data loss is a bit of a red herring.  It's much easier to click the close button by mistake, and besides if an application loses data solely through an instruction to close a window from the WM, that's a bug in that application.

(In reply to comment #74)
> > * Performance-related, the function is a plus. It can save the user time when
> the mouse pointer is at the left of the screen.

Just a small point:

This is true for the time required for the mouse movement (according to Fitts'
Law), but not neccessarily true for total execution time. Having two ways to do
something means having to choose between them, which takes time. Whether there
is a performace gain depends on whether the time difference between the methods
is smaller than the time it takes to make the decision on which method to use.
This is an empirical question that could be researched, but one that probably
depends on many factors (screen size, expertise in mouse use, acceleration
settings, familiarity etc).

When people attempt to close by double-clicking, having it work is, as you say,
certainly a performance gain.

I guess it's just us people that have been using Windows since 2.0/3.0 days that really crave this feature.

In Windows Vista, there is no icon anymore, but STILL Microsoft left the ability to click in exactly that spot for the menu and for the double-click closing.

I rarely (if ever) use the X button to the right, I always double click the title-bar for maximize and only resort to the buttons on the right if the window doesn't behave as I expect (not often).

This is one of those cases where we don't loose anything by adding the feature except the ability to say that we are "doing the right thing", whatever that's worth.

I for one would welcome the ability to double click the top left corner to close.

(In reply to comment #74)

You'll need to restart metacity as well after applying a patch. Or you can log
off and then log in again.
Also, have you tried to build a .deb package as described in comments to
http://blogs.gnome.org/metacity/2008/12/16/how-to-apply-a-patch-under-ubuntu/ (especially comment 2)? This will be more correct, I think.
And sorry, I have no Ubuntu installed now, so I can't check what's wrong. What metacity version are you using? You can check this with `metacity --version`.

To me the only reason to allow the double click on the icon seems to be making metacity usable for users coming from other environments. It doesn't have drawbacks other than being useless for genuine metacity users, in that they probably wouldn't request this if it weren't for compatibility. That's what I read from the above comments.
Personally I am a once-in-a-while metacity user, ie. in the uni or with friends, and I am used to close buttons on the left. Think of Haiku or OS X (albeit I'm using xfwm4 with close on the left). For me it is helpful to be able to double click, since my immediate reflex tends to throw the mouse to the left before I remember what I'm looking at. So I don't think this is useful at all for primary users, but it would make life easier for passers-by and those who use more than one platform.

It's also useful if for whatever reason the top right button isn't visible but the top left one is.

In reply to comment #74

I did restart Ubuntu after applying your patch, but not after applying Thomas' patch. I haven't tried to build the deb packages. Metacity version 2.24.

If Thomas decides to commit the change, I will be more than happy. I am only an occational user of Linux, so personally I can wait. I am still stuck on OS/2, but some day ...
 
I was mostly looking for a patch because I am writing about Ubuntu, and I figure that many of my readers will be missing the double click function.

Not sure why this was closed - enough people seem to want this feature to be able to be configured (including myself).  Sounds like this issue is controversial simply because it is "Windows-like"

Allowing people to configure their Window Manager to behave similar to Windows will allow more people to switch to using Ubuntu from Windows as their daily OS (as I am trying to do).  I have been using this "feature" in Windows for over 18 years (I am 28 so since I was 10!!) and it has become a knee-jerk reaction/hard-wired synaptic response. 

If wide-spread adoption of any distro is to take hold, considerations for how regular users use your OS will need to take precedence over Ego (your refusal to do something simply because it will be "copying" Windows).  If this is a configurable setting that is disabled by default, it will not affect existing users.