Defining an event loop abstraction

[nf2]

Lennart Poettering wrote:

>Therefore I'd like to suggest a different solution: not defining a new
>library, but just defining a new API, specifically a header file. That
>API only provides the bare minmum which is needed to abstract an event
>loop. How could this look like? In Avahi we defined such an
>abstraction in this header file:
>
>http://www.freedesktop.org/~lennart/doxygen/watch_8h-source.html
>
>As you can see, we do not define a single function prototype. Instead
>we define a structure which is kind of a vmt for just seven
>methods. Only two sources of events are known, file descriptors and
>timeouts. (no unix signals, they shouldn't be used by libraries
>anyway, and can be implemented on top of fd events in the application,
>if required)
>
>  
>

Hi,

I think that's a worthwhile undertaking. But i would recommend using the 
GSource (prepare/check/dispatch) scheme for the event loop abstraction 
instead of the one you are proposing in AvahiPoll. The reason is that it 
is more flexible (you can attach x11 sources = toolkit libraries) and 
you don't have to distinguish between file descriptor and timeout sources.

Regarding the "common main loop" i am trying to (optionally) integrate 
Glib main loop into Qt and have developed a patch for Qt3 to run as 
GSource in Glib main loop (and Qt4 will be next).

The main reason for this is that i have a thing called "generic desktop 
adapter library" in mind, which would allow applications to use certain 
desktop features like filedialogs and simple VFS functions from the 
desktop they are running in. The common main loop would be necessary to 
use multiple GUI toolkits and asynchronous VFS libraries "in-process".

More information on the "generic desktop adapter" and screenshots of 
another nice demo called "GParts", which embeds KParts into Gtk+ Widgets 
can be found here: http://www.scheinwelt.at/~norbertf/common_main_loop/

I already had an interesting discussion on kde-core-devel about the 
Qt->Glib main loop patch and got some positive feedback, particularly 
from Trolltech developers (Although they are not very happy with the 
size of Glib and would prefer to link to a smaller library).

http://lists.kde.org/?l=kde-core-devel&m=113143586714273&w=2

Norbert