Garry R. Osgood ([EMAIL PROTECTED]) wrote:
> Simon Budig wrote:
> > I wrote a small program to monitor the extended XInput-Events, it is
> > attached.
> I've not had much time to investigate further on , but these are some trial
> runs I get Built and run on ALICE, an SGI Indigo R4000, using MIPS 6.2
> compiler ALICE 35% xinputev --display harriet:0 (An SGI O2 Xsgi X-window
> server Wacom 4.4.0 device driver)

> Enabling No. 2: "wacom" (Type: 1)
> Enabling No. 3: "mouse" (Type: 1)
> Enabling No. 65244: "Core Pointer" (Type: 0)
> button_press  :  device     3  pressure  0.500  button 2
> button_release:  device     3  pressure  0.500  button -2
> button_press  :  device     3  pressure  0.500  button 2
> button_release:  device     3  pressure  0.500  button -2
> In this configuration, button 3 release is consumed before
> it reaches your code when using the mouse.

My guess is, that the release events simply go to the menu
when the mouse pointer is over it at this time. There seems to
be a problem:

[from ]
: The X server automatically causes a pointer grab when a button is
: pressed, and releases it when it is released. This means that the
: button release event always goes to the same window that received the
: button press event. Xlib allows you to change this behavior, but GDK
: does not. (In the Xlib documentation, this automatic grab is referred
: to as a "passive" grab. It's distinct from an "active" grab initiated
: with gdk_pointer_grab(), described in Section 10.6.2.)

Have a look also at .

IIRC this only applies when the event mask contains both the
to be a problem: Obviously this does not work with XInput-Devices.
(Maybe they are "traditionally" something fundamental different than
the "Core Pointer" and all higher level event processing is left
to the application, and the "AlwaysCore"-mode does not respect this)
So a solution might be:

* when someone presses the button down, grab the pointer until the
  release event occurs (should be done on GDK-Level?)

* prevent the invokation of the menu when the first button is pressed
  down (ugly!).

Maybe this is also related to Bug #6901, "Can not continually move a
floating selection with a pressure sensitive pointer."?



Reply via email to