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

[Peter Volkov <pva gentoo org>]

В Втр, 29/12/2009 в 10:02 +0000, Emmanuele Bassi пишет:
> On Mon, 2009-12-28 at 16:21 +0100, David Nečas wrote:
> > On Mon, Dec 28, 2009 at 12:46:36PM -0200, frederico schardong wrote:
> > > >gdk wraps the business of creating a window and getting events
> > > 
> > > only a window or all the widgets?
> > 
> > X (or Gdk) Window is a thing that can receive events and/or can be
> > drawn on.  Many widgets have their own windows, for instance, text
> > entries or menus.
> 
> 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? 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. 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.


-- 
Peter.