Re: libst + gui = hosted event loop

> If you are going to have to put all the IO in exactly one pthread anyways,
> and have to communicate with it somehow, one would probably be better off
> simply making a slave process that the GUI talks to via a pipe.

Simple:  just port glib to st.  I have no knowledge of glib internals,
but I can imagine that it manages just a few file descriptors that never
change (to wait for mouse/keyboard/graphics events).  Maybe porting that
low-level handling to st is actually realistic.

Otherwise I don't see an easy way to mix two or more separate
event-driven architectures.  Port one library to the semantics of
another, or distill out the common parts and port both libraries to a
new, lower-level library that owns all events/fds, or keep them apart in
separate processes.


-------------------------------------------------------
This SF.net email is sponsored by:Crypto Challenge is now open! 
Get cracking and register here for some mind boggling fun and 
the chance of winning an Apple iPod:
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en