[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of my GTK efforts.

From: Jan D.
Subject: Re: Status of my GTK efforts.
Date: Sun, 30 Dec 2001 17:54:27 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011221

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? */

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())
         if (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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]