Re: Why extension events are disabled by default?

[Owen Taylor <otaylor redhat com>]

On Fri, 2006-09-01 at 18:00 +0300, Tommi Komulainen wrote:
> Hi,
> 
> Does anyone happen to have an explanation why extension events are
> disabled by default in gtk? Having a pressure sensitive touchscreen it
> would be nice to deliver the pressure information all the way to the
> applications, but I'm seeing it's awkward to have the pressure
> information available globally.
> 
> For one, one needs to explicitly enable (gdk_devices_list() +
> gdk_device_set_mode()) "known" devices first to get extensions events in
> the first place.
> 
> Second, one needs to enable extension events on per-widget basis
> (gtk_widget_set_extension_events())
> 
> Third, the above doesn't seem to really work as expected with all
> widgets, for example, GtkButtons. (There's no effect with GTK_NO_WINDOW
> widgets apparently.)
> 
> So, I'm wondering why wouldn't the devices be automatically configured
> to deliver pressure information and similary why aren't all widgets
> getting extension events by default (performance issues maybe?) Is there
> a way around the GTK_NO_WINDOW limitation? It feels like complicating
> the idea of having pressure information available everywhere, for no
> good reason.

I can't really give an exact reasons at this point ... this was pretty
much my first submission to GTK+ in 1997, which is a long time ago.

But I'd basically say that the current situation is due to major
limitations in the the XInput protocol and in implementations of such,
for example:

 * XInput just give you some number of integer valued 
   "valuators" ... there is no hint in the protocol about which.

   It may be a reasonable guess that the first two valuators are the
   X and Y coordinates and the third the pressure, but there is
   no requirement that things be set up that way.

 * Getting extended information for the core pointer is pretty hacky -
   the way that it works is that you get the core pointer events 
   *and* the events for the device, and then you need to ignore the
   core pointer events.

   Back in 1997, things were considerably worse in this regard, in
   ways that I don't remember exactly or want to go in detail, but
   suffice it to say that we used to ship a little "daemon" program
   that you'd run in your session that would negotiate ownership 
   of the core pointer device among different GTK+ programs.

 * Traditionally, if you tried to enable a (serial) tablet in
   XFree86 and it was configured but not plugged in, the app would
   hang for 20-30 seconds.

So assuming that things are right out of the box is certainly not
a good idea.  (Graphics tablets were really, I think, a secondary use
case for XInput; the primary use case was seems to have been a dial
box...)


That explains pretty much why XInput support has to be configured 
to turn it on in GTK+. As for:

 A) Why is the XInput configured per-application rather than global
    for GTK+ via some sort of config file?

    Bad design on my part; I thought it would be easier to just 
    have the GIMP reuse its configuration system rather than add
    something separate for GTK+.

 B) Why do you have to enable extended input events per window?

    As far a I can remember, the main reason for this was that certain
    things like pointer grabs worked fairly unreliably with all
    the hacks to work around the limitations and defects of XInput.
  
    Confining the handling of input devices to the actual draw 
    areas of the GIMP, and not things like menus and buttons made
    it less likely that this unreliability would affect the user.

    It's better now, I'm not sure if it's perfect.

If you can figure out how to reliably deliver pressure with each core
event on the Nokia, I see no reason that you can't just include it
in the GdkEvents, so that:

 gdk_event_get_axis(event, GDK_AXIS_PRESSURE, &val);

Works without any additional app intervention. That's certainly within
the spirit of the current API. 

					- Owen