GNOME Bugzilla – Bug 70482
moving applets, icons, etc. in panel does not always work
Last modified: 2015-03-24 13:00:31 UTC
For some (e.g. volume-control) applets moving them around the panel with the middle mouse button does not work.
Okay, this is a known bug. The problem is to do with press/release events getting across the plug/socket boundary ... I put event forwarding into BonoboPlug/Socket but that only seemed to half fix the problem. This only happens with out of process applets.
I found out something new today... btw I am using a full/fresh Gnome2 install from CVS (as of 19.02.2002). When I change the properties of a launcher/icon in the panel via the context-menu "Properties..." and hit "Close" in the properties-window afterwards the modified launcher/icon cannot be moved anymore. Neither with the middle mouse button nor with the move-command from the context-menu (because I cannot "access"/"get hold of" the laucher/icon anymore). It is still visible in teh panel but it is not clickable anymore. I have to move other, still intact launchers/icons in the panel, around a bit to get the modified launcher/icon accessable again. I hope my explaination is making sense. Otherwise email me.
*** Bug 72624 has been marked as a duplicate of this bug. ***
*** Bug 72626 has been marked as a duplicate of this bug. ***
*** Bug 74995 has been marked as a duplicate of this bug. ***
Ok the problem is with gdk_pointer_grab(). Since the applet is an out of process applet, on a button press the applet grabs the pointer. So in the panel when we try to grab the pointer XGrabPointer() call fails with return code AlreadyGrabbed. I am attaching a patch which does the following. In bonobo-plug.c, where we forward the button press/release events (bonobo_plug_button_press), if ungrab_pointer flag (which has been added) is set then after the XSendEvent() XUngrabPointer() is called. This fixes the problem. An alternative could be that before we call gdk_pointer_grab() in panel-widget.c we check if the applet to be dragged is an out of process applet. If so we traverse down to the bonobo-socket which in turn sends a message to the bonobo-plug to ungrab the pointer the applet has grabbed. This approach may be cleaner because the ungrabbing the pointer by the applet is a requirement of the panel and not for the applets as such. However the patch i have uploaded would not cause any problem. If an app which contains the applets doesnt really require the ungrabbing feature a method can be added which sets the flag. Ofcourse if the flag is not needed and forward_events flags should suffice then the flag itself may be removed.
Created attachment 7244 [details] [review] Proposed patch
The patch also fixes bug #74017
Shivram: please make sure to update the keywords in the future :)
*** Bug 74017 has been marked as a duplicate of this bug. ***
*** Bug 76623 has been marked as a duplicate of this bug. ***
Shivram: thanks for looking into this. So its a pointer grab that's causing the problem? Hmm, I need to think about this ... About your patch, there's no need for that flag because it can never be false and I don't think we should be just doing it for button2 Whether we should be doing it at all is another thing. Removing the sun_patches keyword since we're not going to use that patch
*** Bug 76926 has been marked as a duplicate of this bug. ***
Oh the flag was only to indicate, the flexiblity that can be provided. Without a function to actually set the flag the flag is absolutely useless. Ofcourse this is similar to the forward_events flags, which always true, i think. Hmmm i maybe wrong here. Is there someway when we can actually ask the applet to ungrab its pointer, just before we grab the pointer in the panel. Just a thought :-)
Fixed in libbonoboui CVS