Re: gtk is grabbing my input, how do I stop it...

[Al Amaral <ama jabba East Sun COM>]

> > Date: Mon, 11 Aug 2003 19:15:49 -0400
> > From: Havoc Pennington <hp redhat com>
> > To: Al Amaral <ama jabba East Sun COM>
> > Cc: gtk-app-devel-list gnome org
> > Subject: Re: gtk is grabbing my input, how do I stop it...
> > Mime-Version: 1.0
> > Content-Disposition: inline
> > User-Agent: Mutt/1.2.5.1i
> >
> > On Mon, Aug 11, 2003 at 06:04:15PM -0400, Al Amaral wrote: 
> > > How do I make it stop this behavior?  I've tried making the widgets
> > > insensitive, but that doesn't seem to work...  I don't want to use the
> > > socket and plug mechanism, because of the extra overhead/latency of 
> > > forwarding events through the X server, and I really don't want to
> > > have gtk running the show for me, dispatching requests, again because
> > > of the extra overhead, although if I have to I will.
> > >
> > > Suggestions?
> >
> > If you aren't willing/able to dive into the internals of GDK and
> > figure out what's happening here, I think your approach has no chance
> > of working.
> >
> > (I'm not sure it has a chance even if you are willing/able, but in any
> > case I don't think anyone else will be much help. You're fundamentally
> > doing something strange that nobody else will have much experience
> > with.)
> >
> > You might want to look at the metacity window manager and see if you
> > could structure the code that way, is the only idea I have.
> >
> > But really it sounds like you're doing this the hard way. Why not just
> > have a custom GtkWidget that you then draw to with Xlib code, or
> > something like that, instead of trying to do this embedding stuff.

Because ultimately I want to be able to swap out the GUI with others
and doing something like that would make the code more dependent on GTK,
not less...

For example, we now have a Motif GUI, and we'd like to be able to provide
both.  By doing the embedding the GUI can remain very simple, and my
code can remain simple, with no dependencies on the implementation
details of the GUI...  Right now it's a dynamically loaded shared
library, with some well defined entry points.  I initialize the GUI
and ask it what window I should reparent my window to, and voila...
Likewise, menu picks, dialog box input from the GUI are sent to my
code through a simple interface.  All the logic for handling the
input is in my code, not the GUI, which makes the GUI much simpler.

The window I draw into is irrelevent.  It's the events on my window
that I need to get processed properly, i.e. sent to my window, as
opposed to being processed by GTK.

This is very easy to do in Motif...  Now it looks like I'll have to
add all sorts of code to collect the events that I want on my window
and forward them to my code.  Lots of extra code and overhead for
absolutely no reason.

It's not a total loss, but it makes my job just a bit harder...

What about if I catch the enter-notify and focus signals on the drawing
window, and when I'm in it do an ungrab in GTK?  Why is GTK grabbing the
input devices anyway?  Doesn't make sense, and makes what I want to do
very difficult if not impossible.

I'm going to try the ungrab to see if that will work, and if not I'll
throw up my hands and start doing the input through GTK...

What about Metacity makes you think it might help?  I'm not at
all familiar with the code or it's design, so I don't know what I'd
be looking for.

> > Havoc

------------------------------------------------------------------
Alan Amaral                                 al amaral east sun com
It's not a Sun product called PCi, it's a product called SunPCi...