Re: Widgets not windows, but how to get information about active widget on X layer? (was: What, in detail, the GDK do?)

[Emmanuele Bassi <ebassi gmail com>]

On Tue, 2009-12-29 at 13:40 +0300, Peter Volkov wrote:
 
> > as of gtk+ 2.18:
> > 
> > 	s/Many/Some/
> > 
> > non-top level widgets (where "top level" here mostly means: GtkWindow
> > and sub-classes, even though GtkMenu has to have a real X11 window
> > associated with it for stacking purposes) that used X11 windows through
> > GDK for event handling and drawing purposes now do not have those X11
> > windows any more - though they maintain the GdkWindow object for
> > internal state handling and for ABI compatibility.
> > 
> > usually, a GdkWindow is not associated to an X11 Window unless you
> > explicitly require a XID out of it - at which point GDK will create a
> > native Window and hand over to you its XID.
> 
> But is it possible to find out at X layer what widget is receives input
> at the moment?

no, because a Widget is not a construct that X understands or has any
knowledge about.

>  I'm asking because after widgets started to avoid
> X-windows it became hard-to-impossible to write Punto Switcher killer
> for linux (if interested in code take a look on xneur). This program
> basically follows X input and in case it was written in wrong layout it
> kills the text and rewrites it in correct layout.

this is mostly wrong to do at X level. you should use the input method
mechanisms offered by the various toolkits - both Qt and GTK+ have them.

>  But switching between
> widgets should be handled somehow and now program follows mouse events
> or listens for common accel keys to find out that widget changed. This
> is not a best solution, so is it possible to expose this information
> somehow? Could you share any ideas how this could be implemented? And
> yes, qt has a same problem.

this can only be implemented from within the frameworks of the toolkits,
not from the outside.

ciao,
 Emmanuele.