GNOME Bugzilla – Bug 168726
double-clicking inside the dock slider makes applet unresponsive
Last modified: 2005-03-29 09:19:18 UTC
Found an evil problem while attempting to reproduce Bug 168724 Add a volume control applet to your panel. Click the icon once to pop out the slider. Position the volume around the 50% mark. Now double click on the top or the bottom half of the slider. In both cases, the slider pops back in. In the event that you double clicked on the top half, the volume will gradually increase (over the course of a second or two) until it is at 100%. If you double clicked the bottom half, it will go to 0. You can try to fight it with the scrollwheel or by pulling the slider out again and manually repositioning it, but it always keeps gradually going in the direction you double clicked. The only way to stop it is to remove the applet from the panel.
Due to the possibility of this being a GTK issue, I should mention: GTK version here is 2.6.2.
Confirmed here with current rawhide (FC4). How about we make the slider area itself not do anything on double click? That way it would just be treated like two single clicks with the normal effect of lowering or increasing the volume depending on where the widget was clicked, and force the user to click outside of the widget, or the applet itself to close the slider? I don't think I expected the slider to close on double-click the first time myself at least...
case GDK_2BUTTON_PRESS: gnome_volume_applet_popdown_dock (applet); gnome_volume_applet_run_mixer (applet); this code does not apply to the slider (just the icon) and i don't think there is anywhere else in the code where double-clicking is special-cased. (commenting this out doesn't fix the problem).
This is caused by gtk+ setting a step timer when you start scrolling and not stopping the step timer when a gtk_range widget is unmapped, and also, by the applet not actually unmapping the widget. See bug 168791. There are more direct approaches that could be taken to fix this, but I believe this to be the right way. It will require a small patch (attached) to the applet itself to use hide_all/show_all instead of hide/show.
Created attachment 38061 [details] [review] hello. my name is patch. this patch only works if you also apply the gtk+ patch.
Hi Ryan, wow, weird bug. Ehm, as for the code you looked at, this is used for the slider. You may consider it a hack, but I consider it incredibly useful: I've set the slider dock as child of the actual applet container. Means I only need to write the key/mouse binding code once, so saves a few lines of code. However, the double-click code should only apply to clicking the icon, not double clicking the slider. Kjartan is right there, this is a bug in the applet. Your patch should still be applied, because it is right, but the behaviour also needs to be fixed. Feel free to dup 168724 to this one.
*** Bug 168724 has been marked as a duplicate of this bug. ***
Created attachment 38085 [details] [review] other patch This patch does what I outlined above: double clicks (or, basically, any mouseclick) is not forwarded from child to mouse. This behaviour should only be done for keyboard and scrolls anyway (because clicks are all handled inside the respective widgets already). This patch fixes the bug as well and does not require a gtk release. ;). The patch from Ryan should still be applied, because it is right (I believe).
Comment on attachment 38061 [details] [review] hello. my name is patch. Ryan, feel free to commit this patch and then close the bug as fixed.
Comment on attachment 38061 [details] [review] hello. my name is patch. Arrg, this looks like it missed the tarball I built, uploaded and released. Blocked by freeze, how important is this?
Given that the solution is 'remove applet from panel', I'd say fairy serious and would give my r-t blessing, but a quick note to r-t and promises of first-born children if there is a bug in the patch would be good.
Luis, Davyd, the patch is not directly release critical since the bug is no longer there in Davyd's new tarball. The bug is no longer there. We can breathe again. ;). The patch should still go in because it is technically right. There is no direct bug fixed by it. I'll leave it up to r-t to permit this or not.
If the problem is fixed, I think this can wait.
Stable has been branched. Commited to HEAD.