This has been reported on Ubuntu Launchpad as: https://bugs.launchpad.net/bugs/393672 I noticed that double-clicking window title bars to (un)maximize them requires a faster double-click speed threshold than is used for other tasks in the system. For example, try a relatively slow double-click to select a word in text or to open a directory in Thunar. That same slow double-click does not work to maximize or unmaximize windows in Xfce. For consistency, these threshold for double-click detection should be the same across all parts of the UI. ------ additional information follows ------ It does seem, though, that adjusting the double-click time threshold affects both the title bar and the word-selection, but they still use different thresholds. Also: When I double-click the title bar at the "slow" speed that would be sufficient to select a word, then * the selection _within_ the window temporarily blanks out as if the window was being moved. * the mouse cursor turns to the "hand" as if I were trying to move the window (click+drag). I am using a laptop with a touchpad and with an external USB mouse, but the problem occurs using either. I am using xubuntu-desktop 2.82 xfwm4 4.6.0-1ubuntu3 installed on top of Ubuntu 9.04. xfwm settings: Appearance: - Style: New Wave Dark Menus - Icons: Crux Window Manager: - Theme: Totem - Focus: Raise-on-click is turned off Advanced: - Double click action: *any* added information: I am running Xubuntu "Karmic", 9.10 on a laptop with a touchpad. I just had a thought: what if there's some code that's also looking out for click+drag from the TOUCHPAD that's being used (poorly) in tandem with detecting normal double clicks? @Charlie Kravetz: Are you unable to reproduce on a normal desktop machine? Or do you have a laptop? I have a laptop that has a built-in touchpad that's always on, AFAIK. Perhaps the title-bar click+drag detection prempts (with a different threshold?) normal double-click detection when running on a machine with a touchpad. Something of this sort might explain why the cursor turns to a hand when I double-click too long for the title-bar, but _probably_ still within the normal double-click speed.
I have this same problem on my ThinkPad X61 - which doesn't have a touchpad, but only the TrackPoint. I do not have a desktop to test with though.
No, I double checked (no pun intended) and the timeout for double click is exactly the same. What differs is the distance between the two clicks, xfwm4 allows for just 1 pixel in any direction between the two clicks which is a lot less that the default in gtk+ (and for word selection, I believe the distance is not even relevant, what matters is that the two click occurs on the word, but admittedly I did not check that in the code of gtk+). Anyway, the distance is important and with a small distance of 1 pixel, this is most likely what breaks with the touchpads. I can make xfwm4 use the same distance as set in Xsettings since we even have that in our mouse setting dialog, that would make xfwm4 more inline with other apps that need to make the distinction between click+move and double+click.
I don't think the threshold for double click is what's causing the issue for me. Actually, I am using an external mouse, and i ensure that there is no movement coming from the mouse during the double-clicking. Whether the settings used are identical or not, there is an empirical difference between the title-bar double click (or equivalent alt+double click) and other double clicking. I have a hunch that it has something to do with the mouse cursor turning to a hand on the second of the double-clicks. That is, during the "long" double-clicks on the title bar, the whole window momentarily goes into window-move mode, as if I were dragging it (even though I am not, and in fact I have only double clicked, not tap+drag). It's as if maybe the window manager redundantly _thinks_ I'm using a touchpad and that maybe it thinks I was intending to do a drag with the touchpad. (Drags with touchpad are done with tap+drag.) Maybe it's not the window manager? But, then again, it's *only* with double-clicking the window decoration that this occurs. In short, I don't think movement is the issue. There seems to be a decision-path that's different than interpreting as a double-click for window decorations. Only if the actual double-click is super-fast does the normal/expected decision-path give the double-click behavior. HTH. Thanks!!
Yes, I don't think mouse movement is the problem either. I have this problem on an X61, which has no touchpad ... oh, I've already added that. It happens with any external mouse too. I too notice that the window goes into "move mode" on the second click.
Did you check the code? Did you compare the gtk+ code used to detect double click and the same code in xfwm4? The code is similar, please back up your statements, I am afraid that an "empirical difference" is not enough to investigate this. The window manager does not know nor care what kind of pointing device you use, it deals with X-Window events and timestamps. Anyway, the double click distance is in git master now, I am closing this as fixed as I see no tangible evidence that the problem is not addressed.
Created attachment 3264 Spreadsheet of timings Data generated using: xmacrorec2 | while read line; do d=`date +"%s%N"`; echo $d line; done
(In reply to comment #5) > Did you check the code? Did you compare the gtk+ code used to detect double > click and the same code in xfwm4? No, I have not checked the code. > > The code is similar, please back up your statements, I am afraid that an > "empirical difference" is not enough to investigate this. Unfortunately, that's the only user experience I have! :-) But I think people's muscle memory gets pretty sensitive to this kind of task. > > The window manager does not know nor care what kind of pointing device you use, > it deals with X-Window events and timestamps. > > Anyway, the double click distance is in git master now, I am closing this as > fixed as I see no tangible evidence that the problem is not addressed. Good point! So, I nerded out and tried doing some event logging using off-the-shelf tools to show a difference. Attached (below and with previous attachment) are A) A script I used from bash to capture mouse click events and dump a seconds:nanoseconds timestamp. B) A Gnumeric spreadsheet that plots differences between consecutive mouse Presses and Second Mouse Releases (i.e. total double-click duration, I think). One is for word-selection in the shell (gnome-terminal) and the other is for maximizing a window. The first entries in each are successuful. Middle entries are unsuccussful. Last entry of each is success. Seems to show that the empirical timing threshold is lower for maximize than for word selection. Perhaps another affected user can reproduce this using the attached tool? Shell command and output (uses "xmacro" package): $ xmacrorec2 | while read line; do d=`date +"%s%N"`; echo $d line; done Server VendorRelease: 10706000 XRecord for server ":0.0" is version 1.13. Press the key you want to use to end the application. This key can be any key, as long as you don't need it while working with the remote display. A good choice is Escape. The chosen quit-key has the keycode: 9 XQueryPointer returned: 1 Got Start Of Data Skipping... - Skipping stale KeyRelease event. 1 1291935743523121567 MotionNotify 1251 283 1291935743527852685 ButtonPress 1 1291935743581404671 ButtonRelease 1 1291935743665235856 ButtonPress 1 1291935743709192910 ButtonRelease 1 1291935747452313827 MotionNotify 1143 12 1291935747454469269 ButtonPress 1 1291935747516230328 ButtonRelease 1 1291935747876307380 ButtonPress 1 [...SNIP...]
Created attachment 3265 Spreadsheet of timings (250ms vs 500ms) Updated the spreadsheet to include two different Xfce Mouse Settings double-click threshold times). The original had 250ms. Then I changed it to 500ms and re-ran my test. In the graphs, the second humpsof data are the 500ms setting. Charts on Sheet 1, data in Sheets 2 & 3. Clearly, each is using the setting, but there still remains a discrepency between the two. (Compare the last columns of each of the humps, because these are the first successes after increasing speed of clicking.)
I have not looked at the data yet (don't have gnumeric installed yet) but I wonder, what matters is that the real time measured between events remains within the limits of the double click time. For a double click to be valid it has to verify all of the following conditions: - The time between the two events is inferior than the double-click time - The pointer did not move than doucble-click-distance in x coords - The pointer did not move than doucble-click-distance in y coords If any of these 3 conditions is not met, the double-click is rejected (and interpreted as click+drag or simple-click depending on what happens). Keep in mind that xfwm4 has to distinguish between: - Drag (ie click + move) - Single click (ie press+release) - Double click (ie press+release, press+release again) gdk/gtk+ does not have to be as precise, all it does is counting clicks and measure time between the events. So xfwm4 has another mechanism that gdk/gtk+ doesn't is the timeout, ie xfwm4 needs to implement a timeout in the case the user has clicked and waits (so no other event occurring before the double-click-time) - That's used for example to open the window menu, you can try by yourself, click on the icon and wait, the menu will popup after the double-click-time even if you do not touch the pointer or its buttons at all. So maybe, maybe xfwm4 is more precise than gdk/gtk+, I do not know. If gdk/gtk+ allows for a bit more time is something else, but for me what really matters is the answer to this simple question, is a double-click rejected by xfwm4 while the time between the two click time is lower than the double click time... That would be a bug. For all I checked, I could not see xfwm4 doing the wrong thing, each time the double click time was rejected was because the distance was greater than the defined max distance or the time was longer than the double click timeout set in the preference.
Can you try git master again? I have lowered the timeout priority, to make sure it occurs *after* any possible pointer event (so if an event has the correct timestamp it will be processed before the timeout occurs). If you can, can you rerun your tests and try to identify a case where a double click would be rejected by xfwm4 while the double click time and distance would be valid?