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.

>       Granted it can be 
>     made to work, but we would be using undocumented stuff (I only got it 
>     working by looking at the GTK source) that could break at the next GTK 
>     version.
>
> That is not good.  I need to talk with the GTK developers about this.
> GTK should expose those interfaces to allow an app to maintain
> its own event loop in a clean way that will continue to be supported.
>
> ***Can you please write down a specific list of the facilities you
> would need in order to do this?***  I need that in order to talk
> with them.


There is no good way to first get the next event, and then later tell 
GTK to act upon that event.  This makes it very hard to do your own 
event loop.

GTK uses GdkEvents, so one would think this would work:

      while (gdk_events_pending())
        {
          GdkEvent* ev = gdk_event_get(); /* This does not block */
          if (ev) /* Sometimes there is a NULL event, why? */
            {
              gtk_main_do_event(ev);
              gdk_event_free(ev);
            }
        }


However, this fails to pass the event to GTK widgets (some

internal state perhaps), which makes things like resize strange.

Using gTk_events_pending instead of gDk_event_pending doesn't make any 
difference.

So what I did was override the gtk event handler, and put in my own that 
just saved the event:

static GdkEvent *last_ev;

static void
event_handler(GdkEvent* ev, gpointer data)
{
  if (last_ev) gdk_event_free(last_ev);
  last_ev = gdk_event_copy(ev);
}

and then this loop works:

     while (gtk_events_pending())
       {
         gtk_main_iteration();
         if (last_ev)
             gtk_main_do_event(last_ev);
         
       }


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.

If we are to resuse the X event loop, we really need XEvents.  The only 
way to get to them seems to be to add a filter for each window created. 
 That filter could save the XEvent.

But Emacs sometimes want to handle the XEvent first before passing it to 
the toolkit.  So in order for this to happen, our filter function would 
return GDK_FILTER_REMOVE.  This tells GDK not to pass the event on.  But 
later we want GTK to act on the event, but now we need an GdkEvent.  By 
returning GDK_FILTER_REMOVE, no translation was made.  If we had 
returned anything else, translation would indeed have been made, but 
also passed to the toolkit.

Sa we basically need ether a gdk_xevent_to_gdkevent translation 
function, or even better, an gtk_act_on_xevent function, that 
corresponds to XtAppProcessEvent.

Perhaps one could use XPutBackEvent and then let GTK have its hand on 
it, I havent tried this.

> There is one way in which the GTK-based alternative code could be a
> good thing to install: if on some other system (perhaps Windows,
> perhaps the Mac) we could drop native support and support only
> GTK-based operation.  Then the GTK-based alternative code could
> replace the native code for that platform.
>
> I don't know whether this is a reasonable thing to do on Windows
> or on the Mac.  Can anyone say?


I thought this was possible, but it really don't looks like GTK 1.2 or 
1.3 at least is fully functional on anything other that X.

        Jan D.