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. _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
