For as long as I've used KDE 4.x, triple-clicking the menu icon in the upper-left corner of a window would close the window. This had the same effect as clicking the X in the upper-right corner, and replicated functionality in both older versions of KDE and Windows (though those older versions used a double-click rather than a triple-click; not really sure why this was changed to triple-click to begin with, but I'm just glad the functionality was there). As of version 4.9.0, however, this functionality no longer exists. I can single-, double-, triple-, or quadruple-click as much as I'd like, but it's simply no longer possible to close the window from the left side of the window. This appears to be related to changes made for bug 157184, which includes the following final comment before the bug was closed as resolved: "Add delay before showing window menu. The window menu is shown after a strong click on the menu button. This makes close by double click on menu button working correctly. A single (strong) click will open the window menu, a double click will close the menu. A triple click is no longer required." I have no idea what's meant by a "strong" single click (as opposed to a normal single click), but the end result is that this no longer works at all. Even though the comment implies double-clicking should now work, that also fails. Any chance this can be fixed? While I'm sure only a fairly small number of users were using this functionality to begin with, it's quite handy for those of us still dealing with muscle-memory dating back to the Windows 3.x days. Reproducible: Always
What decoration? Works fine for me with Aurorae decorations and Plastik. I don't think this ever worked with oxygen.
Sorry, should've specified that. This is with the default theme/decorations, Oxygen. Triple-clicking definitely worked prior to 4.9.0 (which I just verified on the 4.8.4 desktop I'm using now), though double-clicking to close never worked, at least not on 4.x.
REassigning to oxygen. Please notice that triple clicking was *never* intended (but the first click opened a menu which had to be closed with the second click to process the third one as doubleclick) @Hugo any changes or custom code in that regard?
If I remember correctly Oxygen disabled the double click by default, see bug #301237
OK, I read through bug 301237 (thanks for the pointer, Martin), but I think I'm still missing something. It sounds like this was disabled because, after fixing the original request to enable support for closing on double-click, it irritated some other people that don't use the feature. So, it was disabled by default with no obvious way to enable it unless you notice this no longer works, search KDE bug zilla, find the right bug report, and manually edit the config file. And even thorugh tripe-clicking worked fine before (if unintentionally), that was also disabled with this change with no ability to reenable it. Is that accurate? If so, here's my problem with this, and why I think I'm still missing something: * First, can someone please explain what a "strong" click is? I see that term mentioned several times, but I can't find where anyone defined it. * I tried enabling the suggested CloseFromMenuButton optoin and restarting, but that definitely doesn't work right. Now, I still can't close the window on double-click, and I also can't bring up a context menu on single click. I can actually close the thing on a quintuple-click (really), so I guess that's something, although not very useful. * If the solution to bug 157184 caused other problems (presumably bug 301237), and then the solution to those other problems was to disable the feature altogether, then we seem to have gone backwareds here. If double-click-to-close can't currently be implemented in a clean way that doesn't cause unintended side-effects, can we simply revert back to how it worked in all versions of KDE4 prior to 4.9.0? Ie., double-click doesn't work, but triple-click works fine, and singl-click context menus work fine. That seems like a reasonable compromise until/unless a a better double-click solution becomes available. Also, just to address a comment Hugo made in bug 301237: "No 'regression' in oxygen (since new 'buggy' (IMO) feature is disabled by default)". I disagree with this. As noted in my second two bullet points above, this is indeed a regression in functionality from <4.9.0, as the triple-click feature works perfectly previous to this, and now it's impossible to close the window from the left side without setting a hidden option (which also doesn't seem to work, at least on my system). I certainly appreciate everyone's efforts on this, but it doesn't seem like this is a good approach, and it's definitely inconveniencing at least me (for what that's worth...), so I respectfully request that this solution be reconsidered.
(In reply to comment #5) > So, it was disabled by default with no obvious way to enable it unless you > notice this no longer works, search KDE bug zilla, find the right bug > report, and manually edit the config file. It was too late to add a UI option. It was after language freeze for 4.9. I hope an option for 4.10 will be added. > And even thorugh tripe-clicking > worked fine before (if unintentionally), that was also disabled with this > change with no ability to reenable it. Is that accurate? The tripple-click was a bug, so that will never come back. > > If so, here's my problem with this, and why I think I'm still missing > something: > > * First, can someone please explain what a "strong" click is? I see that > term mentioned several times, but I can't find where anyone defined it. Strong click means you have to press and hold. A simple press and up again does nothing > * If the solution to bug 157184 caused other problems (presumably bug > 301237), and then the solution to those other problems was to disable the > feature altogether, then we seem to have gone backwareds here. If > double-click-to-close can't currently be implemented in a clean way that > doesn't cause unintended side-effects, can we simply revert back to how it > worked in all versions of KDE4 prior to 4.9.0? Ie., double-click doesn't > work, but triple-click works fine, and singl-click context menus work fine. > That seems like a reasonable compromise until/unless a a better double-click > solution becomes available. no, tripple-click is clearly a bug. I think the solution is quite fine and works with e.g. all Aurorae themes. > > Also, just to address a comment Hugo made in bug 301237: "No 'regression' in > oxygen (since new 'buggy' (IMO) feature is disabled by default)". I > disagree with this. As noted in my second two bullet points above, this is > indeed a regression in functionality from <4.9.0, as the triple-click > feature works perfectly previous to this, and now it's impossible to close > the window from the left side without setting a hidden option (which also > doesn't seem to work, at least on my system). tripple-click was a bug. This is non intentional functionality. I am not aware of any user interface using tripple click. The number of users knowing it has to be very very small. This makes it no regression.
(In reply to comment #5) > * I tried enabling the suggested CloseFromMenuButton optoin and restarting, > but that definitely doesn't work right. Yes, it does. > Now, I still can't close the window on double-click Yes, you can. > and I also can't bring up a context menu on single click. Yes, you can. Try kwriteconfig --file oxygenrc --group Windeco --key CloseFromMenuButton true qdbus org.kde.kwin /KWin reconfigure Works absolutely fine and just as in the Aurorae and Plastik decos (no wonder, given it's the very same code and oxygen just sets the same hint) > I can actually close the thing on a quintuple-click (really) Certainly not. Whatever works or works not, it does not work by sth. that's not a multiple of 2. If you need to click 5 times that means at least one click gets lost, what either means: a) you missed the doubleclick timeout -> raise it (kcmshell4 mouse, andvancedd tab) b) any random amount of clicks may got lost -> You need a new rodent.
@Thomas I can confirm your observations. All works as you describe. Therefore I also agree with your changing the bug title. Now, concerning assignment: should the Gui option be part of the "oxygen windeco" config ? Or more generic (e.g. somewhere in kwin) ? I'm happy with implementing it in oxygen kcm, but maybe you guys have a better location in mind ? (in which case please re-assign accordingly) @martin: - no, no specific code that I know of in oxygen, concerning the menu button behavior. - yes I agree that tripple click should not be re-implemented - I still dont find the current single/double click implementation quite satisfactory (the "strong" single click mostly), but have no better suggestion. Cheers, Hugo
> I can confirm your observations. All works as you describe. > Therefore I also agree with your changing the bug title. Now, concerning > assignment: should the Gui option be part of the "oxygen windeco" config ? > Or more generic (e.g. somewhere in kwin) ? I'm happy with implementing it > in oxygen kcm, but maybe you guys have a better location in mind ? (in > which case please re-assign accordingly) For Aurorae I just implemented it as part of the per-theme config. So considering that it should be in the Oxygen config. Also for Plastik it is in the Plastik config dialog
Ok. will do asap and close this report. Option will remain disabled by default. Hugo
(In reply to comment #7) > (In reply to comment #5) > > * I tried enabling the suggested CloseFromMenuButton optoin and restarting, > > but that definitely doesn't work right. > Yes, it does. No, it doesn't. > > Now, I still can't close the window on double-click > Yes, you can. No, I can't. > > and I also can't bring up a context menu on single click. > Yes, you can. No, I still can't, unless I hold the mouse button down for a second, which is a usability problem. I didn't realize that was even possible when I made my last post. > Try > kwriteconfig --file oxygenrc --group Windeco --key CloseFromMenuButton true > qdbus org.kde.kwin /KWin reconfigure Tried this, and it still behaves exactly how I described. > Works absolutely fine and just as in the Aurorae and Plastik decos (no > wonder, given it's the very same code and oxygen just sets the same hint) I'm happy it works on your specific setup. However, it does not work on either my desktop or laptop, even with the suggestion you offered. Instead, it works exactly as I described previously. > > I can actually close the thing on a quintuple-click (really) > Certainly not. > Whatever works or works not, it does not work by sth. that's not a multiple > of 2. Really? So you think I'm making this up then? I'm sorry that my desktop doesn't behave exactly like yours, but I can count. Two clicks do nothing. Neither do four, nor six. Five clicks, however, do exactly as I described, every time.
(In reply to comment #8) > @Thomas > Therefore I also agree with your changing the bug title. For the record, even though no one seems to either care about my experience or believe that I know how to double-click, I don't. I didn't open this bug because of the lack of a GUI option, I opened it because functionality that was previous in prior versions of KDE no longer exists. I get that the triple-click thing was unintentional, but it still worked. Flawlessly. The new functionality, even when enabled, does not, at least not on my desktop. Plus, as reported elsewhere, it causes other unintended functionality. This is a step backward, and therefore a regression.
> This is a step backward, and therefore a regression. yes, but we won't fix the regression. This was an intentional change to fix the incorrect behavior. I am quite aware of the change in behavior - I implemented it and there was quite some discussion and thought put into the change. The only alternative to fix the incorrect behavior would be to remove it altogether as there is quite some fear that a more agressive approach would result in accidential closing of windows and that's the reason why it's disabled by default in Oxygen. I will also think about whether to disable it for all decorations in 4.10.
(In reply to comment #11) > No, I still can't, unless I hold the mouse button down for a second The timeout is 150ms If it lasts longer for you, you've far more severe problems than this one. > I'm happy it works on your specific setup. That's not "a specific setup" the code for menubutton pressing is: if (lastClient == this && t->elapsed() <= QApplication::doubleClickInterval()) { closing = true; } else { lastClient = this; t->start(); } and for closing: if (closing) { closeWindow(); } So either you miss the doubleclick interval or click another client interim. What also might happen is that you miss the 150ms to release the mouse, thus the popup opens and sucks away the next click. This way of course and amount of clicks can get lost from the doubleclick. What's your doubleclick interval (kcmshell4 mouse, advanced tab)?
I've been doing some more testing on the double-click thing, and think I've figured out why it doesn't work for me. As currently implemented, it seems to require some delay between the first and second click, and my normal double-click speed is to fast for it. So, if I slow down my double-click speed to include a couple tenths of a second pause in between clicks double-clicking to close a window does work. If I double-click at my normal rate (which everything else (that I've tried) in KDE recognizes just fine), the context menu appears, making it look like it only registered a single click. Not sure why this is the case. I'd expect KDE to recognize a double-click as a double-click regardless of where it's used, which is why it didn't even occur to me that I might be double-clicking too fast. Also, I guess that sort of explains the behavior I was seeing with the five clicks - my clicking speed slows a bit with each successive click, so I guess by the time I get to numbers 4 and 5 it slowed down enough to be recognized as double-click. It's pretty amazingly consistent, though. By adjusting the click speed, I can also replicate this behavior with three and four clicks as well. So, I think that leaves us with a new bug: why does kwin (or whatever component is involved here - apologies, I don't know exactly how all the pieces fit together) not recognize my double-click as a double-click when dolphin, system settings, kickoff, etc. all do? I'd guess it's also somehow related to the change made to require a long click to open the window content menu, but that's pure speculation. Anyway, if we can figure that bit out, and if Hugo and company can perhaps come up with a better way to implement the double-click functionality, I think we could finally put this issue to bed in a way that'd make everyone happy. :-) If I may ask one other thing - based on the discussion above, it sounds like the double-click thing does work fine with other decorations (though, I've always been happy with Oxygen under KDE4, so I've never personally tried the rest). If that's the case, then is there any reason why that same solution can't be implemented in Oxygen? Seems like the easiest solution would be to just reimplement a method that's known to work elsewhere. I'm sure there's some technical reason why this hasn't been done, but I'd be curious to know what that is.
(In reply to comment #15) > As currently implemented, it seems to require some delay between the first and second click Not from our side, but yes: moving to game mode clicking, i can trigger the popup by a doubleclick at will > So, if I slow down my double-click speed to include a couple tenths of a second pause You like to exaggerate, do you ;-) The default doubleclick timeout is 400ms, i set mine to 200 (that's 2/10 of a second) and still can doubleclick to close the window. > the context menu appears, making it look like it only registered a single > click. yes. confirmed. > Not sure why this is the case. I'm now gonna track the code. > I'd expect KDE to recognize a double-click there's nothing such as a "doubleclick" - you just click twice in a randomly short amount of time. > If I may ask one other thing - based on the discussion above, it sounds like > the double-click thing does work fine with other decorations It's the very same code everywhere. If it works in one, it works in all - and I could trigger the "doubleclick" menu with plastik as well. Same issue.
<offtopic>Handling double-click is non trivial, the USPTO even granted a patent to Microsoft for it in http://www.google.com/patents/US6727830 (of course if I can implement it, it's nothing for a patent, but it's complex enough that it took me about half an hour to correctly implement the behavior)</offtopic> As a matter of fact Aurorae uses a different implementation than Plastik/Oxygen (QML instead of C++), but the behavior should be absolutely identical.
Have fix for the doubleclick thing. Hugo still has to add the GUI config ;-) https://git.reviewboard.kde.org/r/106227/
I'm not able to cause this with aurorae - the MenuButton.qml logic is different.
Git commit ac95b33e6a3de4d5c92d38a586ed35da0a492de0 by Hugo Pereira Da Costa. Committed on 27/08/2012 at 23:00. Pushed by hpereiradacosta into branch 'master'. Added Option to enable window close on menu double click. M +2 -0 kwin/clients/oxygen/config/oxygenconfig.cpp M +27 -19 kwin/clients/oxygen/config/ui/oxygenconfigurationui.ui http://commits.kde.org/kde-workspace/ac95b33e6a3de4d5c92d38a586ed35da0a492de0
ok. So my part is done. As soon as http://git.reviewboard.kde.org/r/106227/ is pushed, I guess we can close this bug. Will not appear before 4.10 due to string freeze.
... reassigning to kwin, since that's where the remaining double-click issue belongs
Git commit eaf034ccee3c0a03e0a67d1b37cc8c6bd7a0ff23 by Thomas Lübking. Committed on 26/08/2012 at 23:18. Pushed by luebking into branch 'KDE/4.9'. do not show clientmenu if button is down for 2nd click if one clicks very fast, the timeout will coincident with the second downtime (between press and release) what was used to be interpreted as "still down" REVIEW: 106227 FIXED-IN: 4.9.1 M +2 -2 kwin/libkdecorations/kcommondecoration.cpp http://commits.kde.org/kde-workspace/eaf034ccee3c0a03e0a67d1b37cc8c6bd7a0ff23
Git commit cc92ab7488b4fc29a2fdb6ee97662adcfd368fdf by Thomas Lübking. Committed on 26/08/2012 at 23:18. Pushed by luebking into branch 'master'. do not show clientmenu if button is down for 2nd click if one clicks very fast, the timeout will coincident with the second downtime (between press and release) what was used to be interpreted as "still down" REVIEW: 106227 FIXED-IN: 4.9.1 M +2 -2 kwin/libkdecorations/kcommondecoration.cpp http://commits.kde.org/kde-workspace/cc92ab7488b4fc29a2fdb6ee97662adcfd368fdf
Guys 0 just wanted to say thanks for addressing this. Was offline for a while, so I didn't get to respond sooner, but I do appreciate your efforts.