Bug 301237

it is changed to a "strong" click like in Toolbuttons with a dropdown list.

Then I don't see it as invalid. 

Why was this change introduced? One of the main principles of usability is consistency. This principle is violated here in two ways: 

1) Users are used to the old behaviour. Either coming from windows or KDE versions up until 4.9. Why was a change introduced? Also it is not documented in a well visible way, so users used to the old behaviour will, as I did, think it is missing / a bug. As long as there are no good reasons for a change in behaviour, I recommend to not change behaviour for usability reasons. 

2) Buttons behaving the way you describe have a visual mark next to them (downward pointing arrow). This is clearly missing there. Other icons with the same functionality, such as the window icon in other window managers, in windows and in KDE up to know don't behave (and also don't look) like these buttons. 

So I see no good reason for this change, but good reasons against it. Could you enlighten me why this was needed?

see https://bugs.kde.org/show_bug.cgi?id=157184 and the resp. review request for discussion on the addressed conflicts

Well, in the default kde window decoration (oxygen) it worked until and including 4.8. 

So I see it as a bit strange to change behaviour in the default window deco to fix bugs in other decorations, even if they are based on KCommonDecoration. 

Basically you change a behaviour which was there for a few years and which is common in other window managers (and operating systems) fo an even longer time, without giving the user any visual indication of that change. This will confuse long term users, and as there is no visible change nor easy to find documentation on this, it probably will results in more queries (in forms of questions on IRC, forums or bug reports)

I wonder whether the other "bug" is not fixable without changing standard behaviour in the standard theme. Also because both the double click close and showing the menu works at the same time in 
1) the standard decoration
2) other window managers
3) other operating systems 
for quite some time now.

As an addition: 

With the menu _not_ showing on click, the user is actually tempted to click again (at least I tried that), which will then close the window. Depending on the application there is no "Are you sure?" dialogue, which might end up in an unwanted close of an application. So this is not a trivial issue, and might, in the worst case, leave the user with a work- or data loss. 

So I really wonder whether the benefits of this "fix" are worth all the negative side effects coming along. Please consider finding a different fix and revert the behaviour in the default decoration to the default which has been the default in all window managers I can even think of with this feature for years. 

Thank you :) 
(And sorry for commenting twice, I don't think I can edit previous comments. Or at least I didn't find it)

> I wonder whether the other "bug" is not fixable without changing 
> standard
> behaviour in the standard theme. Also because both the double click 
> close and
> showing the menu works at the same time in
> 1) the standard decoration
> 2) other window managers
> 3) other operating systems
> for quite some time now.
As you might see in the discussion to the Review Request, we did 
consider different approaches and tried to find a good solution. As you 
are certainly aware the behavior of double click on close did not work 
on Oxygen (and any other KCommonDecoration derived decoration) which is 
a regression compared to KDE 3.x. The change in question addressed the 
inconsistency between KCommonDecoration and KDecoration derived 
decorations and fixed this long standing issue. Furthermore it is 
unfortunately irrelevant whether other window managers and operating 
systems can implement it correctly. To my knowledge KWin is the only Qt 
based window manager. If you can point us to a window manager written in 
Qt which can do that, I'm happy to look at their solution and apply the 
solution. But based on the investigation it seems to be not possible.

I also want to point out, that there is no visual indication at all 
that the icon is a menu at all. Requesting any visual changes are 
therefore not possible and also out of scope to KWin as we do not 
develop the decorations.

I also want to point out that in general there should not be any 
problem of closing a window by accident due to trying to open the 
window. If an application window closes without asking the user to save 
unsaved data, it is an application problem. Everything else is an 
annoyance but no real issue. Closing a window by accident is something 
that can happen and cannot be prevented (also not the close button).

I also want to point out that it's still possible to open the window by 
right click. If you see a problem just with the delay I recommend to 
switch to right click.

If your concern is about the change in the behavior I want to thank you 
for your concerns, but we considered the change and are aware of the 
implications. The change has been in master for several months without 
any feedback - neither positive nor negative. After beta you are the 
second person to complain - both are extremely advanced users (other was 
a complain on #kde-devel). We will see whether there is a real issue in 
very short time. But personally I am very confident that there is no 
issue and in worst case I might consider documenting it. In general the 
user group which might be unhappy by that change, should be more than 
happy that we still fix regressions compared to KDE 3.

(In reply to comment #6)
> As you might see in the discussion to the Review Request, we did 
> consider different approaches and tried to find a good solution. As you 
> are certainly aware the behavior of double click on close did not work 
> on Oxygen (and any other KCommonDecoration derived decoration) which is 
> a regression compared to KDE 3.x.

I remeber it as working, however, currently only having 4.9 Beta I will try to get a 4.8 on a different machine to re-test that. 

> The change in question addressed the 
> inconsistency between KCommonDecoration and KDecoration derived 
> decorations and fixed this long standing issue. Furthermore it is 
> unfortunately irrelevant whether other window managers and operating 
> systems can implement it correctly. 

Unfortunately not, since when there is a kind of product ("Window manager") and every other product behave in a certain way, being the only exception is horrible with regards to usabilty. People are used to this product behaving this way, similar to like a pedal or a steering wheel works the same in every car. 

> To my knowledge KWin is the only Qt 
> based window manager. If you can point us to a window manager written in 
> Qt which can do that, I'm happy to look at their solution and apply the 
> solution. But based on the investigation it seems to be not possible.

Sounds like a report to Qt would be needed, then. I really doubt that it is technically impossible. Maybe with current Qt it is, in fact if you say so, then it probably is. But that doesn't mean it's not fixable, especially since Qt is open to fixes from the community. 

> I also want to point out, that there is no visual indication at all 
> that the icon is a menu at all. 

No, this is a matter of "being used to it". In fact this is a problem you have very often with icons: there is no real good visual indication that they do what they do, but since they are the same in every application, people are simply used to it. (Example: the horribly outdated 3.5" floppy disk for a save button) 
There is also no visual indication that it is a menu in other WMs offering this feature, but at least they do behave in a consistent way. Again, being the only exception is the problem here. 

> Requesting any visual changes are 
> therefore not possible and also out of scope to KWin as we do not 
> develop the decorations.

Sorry if that came over the wrong way, I would _never_ request a visual change to that button to make it look like one of these buttons with an arrow, since it should simply not be one and not behave like one. I only requested kwin to behave consistent with every other WM out there offering that feature and with the behaviour kwin had for years. 

> I also want to point out that in general there should not be any 
> problem of closing a window by accident due to trying to open the 
> window. If an application window closes without asking the user to save 
> unsaved data, it is an application problem. 

Actions the user did not expect are a bad thing, if the action is critical (such as closing a window) it's even worse. It is of course also a problem of the application if it doesn't ask the user to save data, there I agree with you. But it's as well an error in the window manager if it closes a window by accident. Especially if the accident is very likely to happen due to undocumented behaviour changes. 

> Everything else is an 
> annoyance but no real issue. Closing a window by accident is something 
> that can happen and cannot be prevented (also not the close button).

On the close button the user expects the window to close. On the application icon, he expects a menu to open, since that's what happened in the past and on the other systems he is using. If that's not happening, the user is tempted to try it again, which closes the window. 

> I also want to point out that it's still possible to open the window by 
> right click. If you see a problem just with the delay I recommend to 
> switch to right click.

I recommend to not force the user to give up habits that he had with the same product for years. 

> If your concern is about the change in the behavior I want to thank you 
> for your concerns, but we considered the change and are aware of the 
> implications. The change has been in master for several months without 
> any feedback >- neither positive nor negative.

Because there are probably not many people out there testing master as long as it's not released in any conventient way. Which happens with the first beta tarballs, which happened to be released since a few days, and now you already have two reports. KDE is quite a huge thing to compile, so as an example for me it's not very tempting to have master all the time, with all the problems it brings along. I wait for tarballs to be there, even though my distribution would allow me to install master. Most distributions simply don't offer a convenient way to do so. 

> After beta you are the 
> second person to complain - both are extremely advanced users (other was 
> a complain on #kde-devel).

The function is for advanced users (imo), which makes matters even worse. Advanced users tend to work fast, since they have habits and their body is used to them and works on reflex. So any behaviour change interrupts this trained workflow, and in the worst case the needed attention is not there to prevent unwanted things (like closing an app with unsaved data) 

> We will see whether there is a real issue in 
> very short time. But personally I am very confident that there is no 
> issue and in worst case I might consider documenting it. 

Do you take bets? Just asking because the last time I had a similar report (close windows with the buttons in "present windows" you ended up implementing what I said. I think we had a bet running on how many users close a window by accident with that ...

> In general the 
> user group which might be unhappy by that change, should be more than 
> happy that we still fix regressions compared to KDE 3.

I am very happy with your work, and this report probably sounds way more harsh than it is intended. But a fix which introduces such a huge usability regression  (and being the only product in that genere that behaves different to all the others plus changing behaviour which was there for years _is_ a huge usability regression) is nothing I can be happy with. 

To reduce bug report spam a bit: I'll be in the usual places on IRC this evening, so if you want we can discuss it there :) 

Kind regards

(In reply to comment #7)
> > As you are certainly aware the behavior of double click on close did not work 
> > on Oxygen (and any other KCommonDecoration derived decoration) which is 
> > a regression compared to KDE 3.x.

> I remeber it as working,
No, only "worked" in Plastik decoration, being broken (you had to triple click in double click time)

> Unfortunately not, since when there is a kind of product ("Window manager")
There's no window manager on windows
> and every other product behave in a certain way

The icon in emerald (compiz) is dead space, metacity/mutter afaik doesn't have one and openbox just shows the menu but as much as you click won't close the window and i will eat whatever you demand if you find such feature in eg. OSX.

This "feature" is just a leftover quirk from Win3.11 (where there was no close button, windows were closed using the menu and double clicking the menu icon was a shortcut to it)

The only other way to do this would be to handle the grabbed second click from the menu and forward it from the menu to the icon before the popup closes and in doubt closes the window - the menu however inevitably opens interim for this approach (and win 3.11 had no "disturbing" showing/closing animations)

> Actions the user did not expect are a bad thing,
What is why double clicking an icon should not close anything anyway, but the feature seemed demanded enough for Martin to take action in this regard.

> The function is for advanced users (imo), which makes matters even worse.
> Advanced users tend to work fast, since they have habits and their body is
No guess what the 400ms timeout would have caused (i've tried the patch then and immediately closed the window (xterm, i tend to test on irrelevant dummies ;-)

(In reply to comment #8)
> (In reply to comment #7)
> > > As you are certainly aware the behavior of double click on close did not work 
> > > on Oxygen (and any other KCommonDecoration derived decoration) which is 
> > > a regression compared to KDE 3.x.
> 
> > I remeber it as working,
> No, only "worked" in Plastik decoration, being broken (you had to triple
> click in double click time)

*augh*, sorry, I was refering to the window menu. Because I don't care about closing the window with double click too much myself (but for consistency reasons probably it has to be there). The menu did work, didn't it? 
 
> > Unfortunately not, since when there is a kind of product ("Window manager")
> There's no window manager on windows
> > and every other product behave in a certain way
> 
> The icon in emerald (compiz) is dead space,
> metacity/mutter afaik doesn't
> have one and openbox just shows the menu but as much as you click won't
> close the window and i will eat whatever you demand if you find such feature
> in eg. OSX.

Again, I am talking (the whole bug report long) about the  "single click -> show menu" function, not  "double click -> close". This was probably a missunderstanding. Fluxbox, openbox (and probably other derrived *boxes) do show this menu, windows does, kwin did, a few don't have this functionality (that's why I wrote " consistent with every other WM out there offering that feature" instead of "every other WM out there"). I am not sure about xfwm to be honest, I'd have to try that. 

So the (sorry for the misunderstanding) thing I wanted to write: Every WM offering that feature (menu on the app icon) behaves "opens menu on single click", and not  "opens menu on long click". 

> [...]

Again, sorry: my main issue is not the closing (I am, from a personal point of view, also not a fan of putting such a critical function into an icon where the user doesn't expect it. But this has been decided (and kept, current windows still does it) a long time ago). 
My main issue is the window menu :) 

> > The function is for advanced users (imo), which makes matters even worse.
> > Advanced users tend to work fast, since they have habits and their body is
> No guess what the 400ms timeout would have caused (i've tried the patch then
> and immediately closed the window (xterm, i tend to test on irrelevant
> dummies ;-)

Yes, I read the discussion, and I have to agree that this solution probably would have been worse. 

Again, what I am missing is the behaviour I used to have  (I left clicked the icon -> got my window menu), and which has been changed to fix a bug with a different feature (closing the window). So for users who are used to open the window menu that way it is a regression wrt. usability. 

(As a minor sidenote: Yes, I am aware of two other possibilities to open that menu and that work just fine. A good reason for having it on the icon is the fact that this icon is in a hotspot when the window is in a maximized state.  (You don't have to "aim" with the mouse, top left corner in standard configuration). But yes, I can and will probably either just patch it back for me, or adjust my behaviour. I just feel that such usability regressions should not be made, and "nobody gave feedback so far" is not really an argument if "so far" was an unreleased version people had to build from git, and as soon as you actually release it you get two. 

Anyway, I'll stop disturbing you here. I'll try to discuss this with Martin next time we see us on IRC in depth if he wants (feel invited to join if you want), I'll see if I am annoyed enough by it to actually revert it for me or if I'll just adapt to the keyboard shortcut. 

Thanks for the good work on kwin in general :)

The decoration can control whether the icon doubleclick closing should work (and thus this trade-off is necessary)
-> renaming, re-opening as wish and assigning to oxygen (currently hardcoded, could be an option but requires string break unless it's possible to steal the i18n from plastik)

I have not read the entire discussion.
Nonetheless let me see if I understand things right:
1/ close window on double click on icon button was not working with oxygen
2/ click on icon button was opening the menu instantly.
Right ? 

Now: 
3/ close window is working
4/ menu opening needs strong press.

and I'm ask an option to "disable 3". Would then the menu be opened instantly, as was the case before ? 
I think that is the point of the whole thread, no ?
Note: I never recieved an oxygen bug report asking for the "close on double-click" feature in oxygen deco ...
(so I'd be rather inclined to just disable it 'cleanly', if it allows users to have instant menu opening)

Comments ? Did I miss the point completely ?

PS (to kwin devs): likely you discussed it already
would there be a way to open the menu on single shot click after a double-click-time delay, in case no doulbe click happened ? I personally would prefer it to strong click.

Note: the fact that nothing happens on "single short click", is quite bad, UX based, I think. I have no other example of such thing happening elsewhere in mind, in any app. This does not make it like a "menu-toolbutton", where the whole point is that you have a different action between short and strong single click. not "nothing - something".

Hi Hugo :) 

Speaking for me here: 

Yes, I would like the window menu to pop up instantly on a single mouse click on the application icon in the titlebar. 

If this means that the close-on doubleclick has to be disabled: I can live with that, since it was a horrible thing in the first place. So yes, for me this would be an acceptable solution. 

(I fear that maybe a diferent user has different views) 

Kind regards

re-added KWIN devs in the discussion, cause I'm not sure that it is over.
I'll try to discuss with martin on IRC too, some day.

diff --git a/kwin/clients/oxygen/oxygenclient.cpp b/kwin/clients/oxygen/oxygenclient.cpp
index 59d615e..6f73c88 100644
--- a/kwin/clients/oxygen/oxygenclient.cpp
+++ b/kwin/clients/oxygen/oxygenclient.cpp
@@ -193,7 +193,7 @@ namespace Oxygen
         {
 
             case DB_MenuClose:
-            return true;
+            return false;
 
             case DB_WindowMask:
             return false;


Regarding "waiting for doubleclick interval" - that was actually Martins first approach to solve the conflictive usage, but it means there's a (by default) 400ms lag between clicking and opening the dialog and if you "missed?" click again you close the window, so i suggested the strong click (see RR for details)

Quoting myself:
> The only other way to do this would be to handle the grabbed second click from the 
> menu and forward it from the menu to the icon before the popup closes and in doubt 
> closes the window - the menu however inevitably opens interim for this approach 
> (and win 3.11 had no "disturbing" showing/closing animations)


Personal opinion, no official KWin/KDE statement:
---------------------------------------------------------
About the "feature" itself - it will *never* appear in bespin, i guess that explains my opinion enough.
Since however oxygen is the default decoration and -cruft or not- it's an apparently demanded feature from MS OS emulation, my recommendation would be to have it optional, off by default (and try to bring in the term "idiot" alongside the checkbox ;-)

If you cannot (don't want to) break string freeze for 4.9 i'd also disable it w/o GUI config until 4.10 because that's not a regression for Oxygen (unlike Plastik, afaik only deco to have supported this so far since redmond is gone) while the double click is by all means (there *is* a UI usage conflict and however it's resolved, it will be some trade-off)

@Thomas.
Thanks for the clarifications.
Yes I'll turn the feature OFF by default (to come back to old behavior) and will add a hidden option.
Since nobody complained about this "missing" feature on the oxygen bug-lists, I don't expect much complain.

> Yes I'll turn the feature OFF by default (to come back to old behavior) and
> will add a hidden option.
I think this is a good solution
> Since nobody complained about this "missing" feature on the oxygen
> bug-lists, I don't expect much complain.
The bug was open on kwin side - see #157184

Git commit 621b769a3d72cd2f7b89e805919a4f82aff24d9c by Hugo Pereira Da Costa.
Committed on 07/06/2012 at 21:28.
Pushed by hpereiradacosta into branch 'master'.

Added hidden configuration option to enable/disable closing windows by clicking on menu button.
Option is called "CloseFromMenuButton"
It is false by default.
To turn it on, add
  CloseFromMenuButton=true
in [Windeco] section of $HOME/.kde4/share/config/oxygenrc.
Note that it results in poor usability of the menu button, if enabled.

M  +1    -1    kwin/clients/oxygen/oxygenclient.cpp
M  +8    -0    kwin/clients/oxygen/oxygenconfiguration.cpp
M  +12   -0    kwin/clients/oxygen/oxygenconfiguration.h

http://commits.kde.org/kde-workspace/621b769a3d72cd2f7b89e805919a4f82aff24d9c

Now this fixes it for good.
No 'regression' in oxygen (since new 'buggy' (IMO) feature is disabled by default)
And demanding use can still turn it ON, if needed.
I 'might' make it a real UI config option for KDE 4.10

Thanks for the good work guys, and sorry for all the hassle :)