Version: unknown (using 4.2.87 (KDE 4.2.87 (KDE 4.3 >= 20090519)), Gentoo) Compiler: x86_64-pc-linux-gnu-gcc OS: Linux (x86_64) release 2.6.30-rc3-dirty ATM this is a setting belonging to the Plastik window deco, but most others also show the application icon so imho this should to the window behavior config group. Furthermore, the context menu should not pop up when double-clicking the icon - this needs another timer to wait if it's a single or double click...
the button belongs to the deco, one could add this behavior to the std. button implementation, but there's no guarantee that it's used by the actual deco and the second point (delay opening the popup) makes me wonder if this is really a great feature. just assume the user clicks the button, the menu doesn't appear, user assumes some error on his side and clicks again (or s/he just accidently performs a dbl.click) -> window's closed :-( so you trade in a delay on opening the context menu (main purpose of this button), the risk of accidental window closes (there's probably a reason why many WM use a big fat red button for closing, maybe even taken apart from all other buttons) and possibly a bunch of bug report à la "doesn't work with deco xyz i downloaded from kde-look.org" for exactly what gain? (sidenote: seems to be broken in plastik atm?)
Well ok sane reasoning. That's probably why windows does only open the window menu when right clicking the app icon.. it does, doesn't it?
windows has no menu button, but just a window icon - kwin provides a menu button that - in many cases - actually paints the icon as well and is by this used to play the window icon role as well. applying this to a window icon is unfortunately neither w/o problems. 1. right clicking the entire deco currently shows the menu, left clicking it enters moving and double clicking does configurable stuff (maximizing, shading, ...stuff) and different from windows the titlebar layout isn't fixed (i.e. assume title and icon centered (e.g. check the keramik deco) so the icon could easily be dbl.clicked by accident 2. many decos would have to replace the menu button or live with the fact of a minimum 2 button requirement to access the menu (and where apple just dropped out - in a way - touchscreens drop in...) just for curiosity: what's the point about having an item on the titlebar that 1. behaves different from all others (double instead of single click) 2. this way triggers an inreversible action (closing) 3. (in case of icon and many decos) does not indicate it's active state on hovering (and in relation to e.g. taskbars will easily be taken as simple indicator) 4. is redundant to a dedicated item that explicitly indicates the resulting action? hint: "windows does it" does not count ;-P
> hint: "windows does it" does not count ;-P humm... in that case, i'm out i guess XD it's just out of bad habit... i have placed the close button left of the menu button anyways so uhhmm.. it's just that the window deco provided me with the option and well it didn't feel right.. neither does it work right atm. Wha'eva ;)
KCommonDecoration seems to have been prepared for this... roundabout 2005? @sandro: do you want to keep it or kick it?
Indeed "double click close" seems to be broken. I'm going have a look at it as soon as I get around pulling a snapshot of kwin again... At least the Redmond decoration would profit from this feature working again. I'm not sure if the option in Plastik should stay, though (it seems no one has been caring about it being broken for about 4 years).
I care about it being broken, having it used it quite often on KDE 3.5, I'm pretty used to it. Also, a Google search for "close windows by double clicking the menu button" will show that others care, too.
*** Bug 182716 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 157184 ***