Re: Status of my GTK efforts.

[Jan D.]

Richard Stallman wrote:
> 
>     > No, it means more code, and more complexity.  We must keep supporting
>     > XTread_socket.  Your way, we would have to support both that and another
>     > way of doing the same job.
> 
>     It is not really the same job.  It looks like it is the difference
>     between making GTK work or not.
> 
> If the old code can't work, I guess we need to install other code for
> this job.
> 
>     Well, works is a relative concept.  This still handles GdkEvent:s, not
>     XEvent:s, it filters WM_protocols, does compression of enter/leave and
>     so on.
> 
> Given that GDK has its own event type, I guess it is not unreasonable
> that it wants to use that type.  So I think the real question is, does
> the support for that type enable apps to do what they need to do.
> 
> You mentioned one flaw, that you can't pass the GdkEvent to GTK and
> get its widgets to handle the event.  I'd like to have a "complete"
> list (or as complete as your experience can give you) before I talk
> with them.

I could not do that in the "obvious" way (get the next event and then pass it
along).  It does work if I override the GTK event handling function and supply
my own that copies the event and later gives it to GTK (see previous mail).

I'm no expert on XIM, but GDK does a lot of that internally.  It sets its own
InstantiateCallback, I am not sure how this would interract with Emacs XIM
handling.
> 
> Could you explain in more detail what it means to filter WM_protocols,
> and what it means to compress enter/leave events?

When GTK gets an Enter notify event, it peeks at the next event and if there is
one and it is a Leave notify, it throws those two events away.  The same is
done if first a Leave notify event is followed by an Enter notify. As this is
done in GTK, only GTK widgets should be affected.

GDK has a function that lets the programmer set a filter for ClientMessages and
specific Atoms.  By default, gdk installs its own filter for WM protocols. 
This filter turns wm_delete_window events to an GDK event of type GDK_DELETE
and drops all others (like wm_take_focus, wm_save_yourself that Emacs acts
upon).  Emacs would have to put in its own filter that would override the GDK
default filter.

        Jan D.