Since quite a few people, including me, are using ROX filer in conjunction with Blackbox, I thought someone might help bring some insight into this discussion.
On Tue, 2002-05-28 at 06:04, Thomas Leonard wrote: > > > > When the mouse button is pressed, the event is sent to ROX-Filer and the > > filer is given the pointer grab, so all mouse events get sent to the filer > > until the button is released. > > > > Window managers like twm only keep the menu open while the button is held > > down. To get motion and release events sent to the menu they need to grab > > the pointer, which they can't do if ROX-Filer still has the grab. > > > > Normally, the root window would get the grab (owned by Blackbox), but if > > the event is forwarded then it won't get it. Perhaps getting a release > > event sent to the menu confuses it (since all events should be going to > > the root window which it thinks has the grab)? > > > > Blackbox should probably do an explicit grab to fix the problem... > > > > > >-- > > Thomas Leonard http://rox.sourceforge.net > > [EMAIL PROTECTED] [EMAIL PROTECTED] On Tue, 2002-05-28 at 01:15, Ryan Harris wrote: > Well, I fixed the problem. See the end of this post for the information > I had planned on sending about the problem. Now, I just wanted to > understand the ramifications of my change. > > In pinboard.c, line 952, > function static void forward_to_root(GdkEventButton *event) > > if (event->type == GDK_BUTTON_PRESS) > { > xev.type = ButtonPress; > XUngrabPointer(gdk_display, event->time); > } > else > xev.type = ButtonRelease; > > What is the reason for ungrabbing the pointer? Commenting out that > line, completely fixes the problem I am describing below with no ill > effects to either Blackbox or Sawfish. At least as far as I can tell. > Well, hopefully someone a little more knowledgeable can help me from > here. :) > > ///Post prior to fixing > I've noticed an oddity with the button forwarding. It seems that the > filer is forwarding two button clicks to the underlying WM. > Specifically, I see this behavior with the button 3 forwarding, but I am > assuming the same is occuring with button 2. Let me explain in the best > of my understanding. > > First off, I am running blackbox. So, I will demonstrate the behavior > from this perspective. > > Each "click" is comprised of two actions, a click and an unclick. With > the filer running, if I perform a button 3 click (click, unclick > combination), the root menu mysteriously disapears. If, however, I > perform only the first click, without the unclick, the menu remains. > Moving the pointer off of the menu before the unclick, allows me to > access the menu. Now, I perform only the click, again without the > unclick, and attempt to access the menu. Here we see odd behavior. The > menu functions, highlighting the selection. I cannot access anything, > but I assume that is because I am still holding button 3 and cannot hit > button 2 simultaneously. This seems consistent with normal blackbox > behavior. > > Ok. Here is where we are: > > 1a) Click/unclick on menu -> menu dispapears > 2a) Click, move pointer, unclick off of menu -> menu remains, can access > 3a) Click and attempt to access the menu -> menu highlights, cannot > access (see above why this doesn't matter?) > > > At first, I thought this was an issue of Blackbox not treating the > backdrop correctly (i.e. the backdrop was being raised above the menu), > however as I hope to show, it doesn't seem to be the case. > > Now, using Blackbox without the filer. > > 1b) Click/unclick on menu -> menu remains > 2b) Click, move pointer, unclick off of menu -> menu remains, can access > *3b) Click and attempt to access the menu -> menu does *not* highlight, > cannot access > > Now, 1a, 3a, and 3b, lead me to believe that the filer is forwarding two > clicks (click/unclick, click/unclick) for each event. > > First, the only way to recreate 1a without rox running is to perform a > click/unclick, click/unclick combination with the second being performed > over the menu (obviously there is no menu for the first combination). > > Second, the only way to recreate 3a without blackbox running is to > perform a full click/unclick (the position of the unclick is > unimportant). Performing only a single click, holding the button > without an unclick, will not allow you to access the menu. However, a > *single* click with rox running does access the menu. > > > One more piece of information. Button 2 *appears* to work. However, I > believe this is only because Blackbox treats button two differently. > Button 3 is used to bring up the root window, and cancel actions (i.e. > get rid of the menu). Button 2, however, does not perform this task. > So, a click/unclick, click/unclick combination leaves the menu running. > > Ok, that was a mess. But, I realized writing this it is pretty > difficult to describe. I've attempted to look through the code and > change some things to no avail. > > The relevent code ssems to be in pinboard.c: > > line 992 button_release_event(...) > line 1007 button_press_event(...) > > And maybe most importantly, > line 952 forward_to_root(...) > -- > Ryan Patrick Harris (maxter) > [EMAIL PROTECTED] > University of Michigan EECS > http://maxtersbox.net > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > rox-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/rox-devel > -- Ryan Patrick Harris (maxter) [EMAIL PROTECTED] University of Michigan EECS http://maxtersbox.net
