Re: External event loop for glib?
- From: Tim Janik <timj gtk org>
- To: gtk-devel-list redhat com
- cc: Antti Huima <huima ssh fi>
- Subject: Re: External event loop for glib?
- Date: Mon, 22 Mar 1999 22:29:37 +0100 (CET)
On Mon, 22 Mar 1999, Antti Huima wrote:
> Dear all,
>
> We are strongly considering adding GTK+ support for the UNIX-versions of
> several of our products. While some of the products are commercial, we see
> that GTK+ support would strongly benefit the case of the users of the SSH
> products.
>
> The only major problem seems to be that glib has its own event loop. We
> have an own event loop and would prefer using it instead.
>
> I have the following questions:
>
> a) Am I correct in that the best way to change the eloop implementation
> currently is to reimplement the appropriate glib functions?
not really. if you already have a main loop implementation up and running,
you simply need to call g_main_iteration() to keep gtk alive.
you'd want to select(2) on the Xserver connection file descriptor though,
so the GUI doesn't starve when new events are available.
keep in mind also, that you can't use the gtk main loop functions in this
case, (gtk_main_quit(), gtk_quit_add() handlers) as there will be no gtk loop
instance.
you should take a look at glib's idle and timeout handlers, they provide simple
examples on wrtiting new GSources, which would be the way to go if you
consider hooking your loop mechanism into glib's main loop mechanism. with
GPoll there's also generic support for selecting/polling on file descriptors
available, and you can easily provide your routines with a higher priority
than gtk ones.
> b) Could the glib development team accept a patch that implemented a
> generic interface for using an external event loop and
> co-operate in designing such a patch (as the glib documentation is
> not *that* extensive yet)?
with g_main_iteration() and g_main_pending() being provided already, such
patches are probably not neccessary. if you encounter bugs in the current
system or provide cool enhncements, LGPLed patches are usually very much
apprechiated.
> c) Is the licensing policy of Glib/GDK/GTK chaning in foreseeable
> future to something else from the GNU Library License? (In particular,
> to something that could prevent its usage in a commercial program that
> is not necessarily distributed as free source?)
no, this will never happen, as the LGPL itself already guarrantees that
there will always be an LGPLed version of these libraries available.
>
> --
> Antti Huima
> SSH Communications Security Oy
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]