Re: External event loop for glib?
- From: Helge Hess <hh mdlink de>
- To: gtk-devel-list redhat com
- Subject: Re: External event loop for glib?
- Date: Tue, 30 Mar 1999 00:08:28 +0200
Hi Owen,
I can fully understand the opinions you gave and I have nothing against
the glib runloop in principle. As far as I can see it would be possible
to reimplement NSRunLoop using glib, but that is quite some
(integration) work from my first and second impressions (eg emulating
modes is a topic).
What I wonder is whether all this is really necessary. Eg I cannot see
why it is necessary to have prioritized fds for a GUI toolkit ! I can
hardly believe that more than timer, perform-later's and fd's (actually
only one) are necessary to implement a GUI.
So, if someone requires runloop features of glib, he might use that in
another thread or write an appropriate wrapper class, but the gtk+ ObjC
approach I want to take is intended for OpenStep ObjC developers which
are familiar with NSRunLoop, not with glib runloop. I would like to
integrate gtk+ with existing systems and not to replace these.
So IMHO the real question is not how to integrate other runloops with
glib runloops, but how to integrate other runloops with gtk+ ! You could
put down the features absolutly necessary to support gtk+ (not glib) and
we can see whether we can provide them.
best regards
Helge
ps: Modes in NSRunLoop are used primarily by the distributed objects
system. A mode is a named collection of event sources, so you can select
such a set by simply switching the mode. Eg when doing DO you want to
receive reply-messages from multiple DO clients while not receiving GUI
events (for various reasons). Recursive runloops in glib might be a
better(cleaner) approach, but not necessarily.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]