intentionally and required if you want to also close the window by doubleclicking that button:
https://git.reviewboard.kde.org/r/103995/

Considering this behavior is inconsistent with Oxygen, I didn't find this feature to be very discoverable. I actually thought the menu icon was broken altogether until one time I just happened to hold my mouse button down for a bit after clicking. I would never have thought to close a window by double-clicking on this icon, especially with a close button already part of the window decoration. Is this a convention of some sort that I have missed all these years? It seems a pretty strange one (at least to me).

Anyway, perhaps at least Oxygen and Aurorae should be made to behave the same way to avoid confusion?

Afair it's some windows thing, oxygen optionally supports it as well, plastik used to have it, but it was long time broken.
https://bugs.kde.org/show_bug.cgi?id=79678
https://bugs.kde.org/show_bug.cgi?id=194438

Aurorae indeed uses it by default, don't know the reason.
   -> Martin?

About the feature itself:
Well, Bespin does not and will not ever support it ;-P

However, if you want to allow closing a window by dbl-clicking the menubutton, some resolution /is/ required. If you've a better one, propose it =)

IMO, a better solution would be:
1. After the user clicks on the window menu icon, a timer is initiated (we'll say 200 ms).
2. After the 200 ms elapses, if no further clicks were made on the button, the menu will appear.
3. If, before the 200 ms elapses, one or more additional clicks were made on the button, then the window will close.

This solution would allow for a quick press and release of the mouse button, preventing the discoverability issue whereby a user must know to click and hold the button down on the window menu to open it up. As someone who is quite adept with computers, it took a happy accident for me to discover that the window button wasn't actually broken.

See discussion on reviewboard.
200ms is a notable lag, the default doubleclick interval is 400ms, what would be the time required to show the menu (instead of 150ms as is now)
Hybrid (open after 150ms press or a known single click after the doubleclick interval) and an aditional DontAskAgain dialog may be a solution.
(Otoh, if one had to explicitly activate the feature, there just could be a label hinting to press longer)

I decided to fire up VirtualBox and see how Windows handles this scenario. Here are my findings:

Windows XP:
  1. Pretty much the same as my proposed solution in Comment 4, with the menu appearing approx. 500 ms after clicking on the window menu icon.

Windows 8:
  1. Clicking on the window menu icon causes the menu to appear instantly.
  2. If a second click is registered on the window menu icon within the double-click period, the window is closed. So, the behavior when someone double-clicks on the window menu icon is the window menu briefly appears before the window is closed.

Either of these solutions works well, and is less confusing than KDE's current method, IMO.

That being said, does anybody know how many people actually use the double-click to close functionality? Perhaps this option should just be disabled by default for Aurorae decorations as it is for Oxygen. BTW, I am only assuming it is enabled by default, since it is enabled on my system, and I don't remember manually activating this feature.

Tried Win7 which behaves as Win8, what -to me- seems rather unfortunate:
If I open the popup, change my mind and close it by clicking it again "quickly" (it's not a doubleclick as I usually perform it) - the window closes.

The feature is default active on Aurorae (I know that from code)
It's Martins choice, but I agree I should perhaps not.

My understanding of the behavior is the legacy of Win3, which had Minimize, Maximize and a Menu, but no Close button.
So the doubleclick became a shortcut to the close entry in the menu.

There will be people using it (see linked bugs), but since Win95 introduced an explicit close button to that environment, it's only preserving dated habits - why would one seriously want to *close* a window with a doubleclick on the *menu* instead of a single click on the *close* button?

For Aurorae, the theme might have a word on it (eg. a "Redmond" theme would default to it), but I would not want to sell this Windows oddity as the most natural thing in the world, the way titlebars just are.

I think leaving KDE's current click/hold behavior and just changing the Aurorae default would be the most sensible solution. That way, people who want to double-click their menu buttons can enable it (and they'll be more likely to correctly figure out the current behavior, knowing its related to what they enabled). Besides, I'm sure all of you awesome KDE devs have far more important matters to tend to than perfecting a legacy Windows mechanism that arguably isn't really even necessary.

The reason it's enabled by default is that it used to be enabled by default in general, just was broken. Once we fixed the general brokeness Oxygen maintainers didn't like it and changed the default in Oxygen.

I personally don't mind whether it's this way or that way and I don't think that there is a need to have the decorations behave the same way by default. They are different decorations providing different features for a reason.

(In reply to comment #10)
> I don't think that there is a need to have the decorations behave the same way 
> by default.

I agree on this but didn't change my mind reg. the feature itself =P

Also Christian then has a point about detectability, since the behavior is "odd" and will only be known to a minority of users (I recall to have randomly detected it on Win3.11 -where it acts as on Win7/8- and never felt like using it on Win95 or XP)

Sum up:
------------
- strong click (KWin):
  hard to detect if you've not the least idea about a pot. different behavior of the menubutton

- delayed showing (app. WinXp):
  slows down UI and feels laggy, pot. trapping users into unwanted doubleclicks (click, no reaction, click again for the assumption of a failed mouseclick)

- immediate showing and waiting for pot. double click (win3.11/7/8)
  * prone to accidental doubleclicks (to re-hide the popup)
  * the popup can show under the mouse, covering the button -> you maximize instead of closing
  * implementation issues as the popup sucks the mouse input. we'd have to compare the mouse on closing the popup, what is "dangerous" if the popup was closed by [esc] etc. -> we'd have to export the closing and closing reason to the decos ...

-> Either the user has to know about the feature (resolves strong click detection  issue) or we could go for a Hybrid between KWin and WinXP (catch a normal click, timeout the doubleclick interval, show the popup and a "run once" dialog telling the user: "delayed popup because double click closing, if you want the popup faster, just keep the mouse pressed"

or change the default in Aurorae and add the information in the config dialog

That was teh implication, yes ;-)

> That was teh implication, yes ;-)

ok, it ended on my todo list :-)

Step 1: show an information https://git.reviewboard.kde.org/r/116715/

Step 2: change the default https://git.reviewboard.kde.org/r/116716

Git commit 99c6412d92dcc86d0da6ec8e064f882d61304428 by Martin Gräßlin.
Committed on 11/03/2014 at 14:11.
Pushed by graesslin into branch 'master'.

[kwin/aurorae] Default to no close on double click menu button

To increase consistency with other decorations and because it changes
the behavior of the menu button in an unexpected way we default to
double click menu button doesn't close the window.
FIXED-IN: 5.0
REVIEW: 116716

M  +3    -3    kwin/clients/aurorae/src/qml/MenuButton.qml
M  +2    -2    kwin/kcmkwin/kwindecoration/decorationmodel.cpp

http://commits.kde.org/kde-workspace/99c6412d92dcc86d0da6ec8e064f882d61304428

Git commit 871a617be5acc3f677a31183797cb5299d702c5e by Martin Gräßlin.
Committed on 11/03/2014 at 14:03.
Pushed by graesslin into branch 'master'.

[kwin/kcmdeco] Show an information if close window by dbl click gets activated

The option changes the behavior of the menu button, thus we should point
out to the user that the behavior changes.

This is only done for Auroae configurations as other decorations have to
take care about it themselves.
REVIEW: 116715

M  +10   -0    kwin/kcmkwin/kwindecoration/auroraeconfig.ui
M  +9    -0    kwin/kcmkwin/kwindecoration/kwindecoration.cpp

http://commits.kde.org/kde-workspace/871a617be5acc3f677a31183797cb5299d702c5e