Qt->glib main event loop patch (common main loop)

[Vinay Khaitan]

> we offer, and will continue to offer, lots on the freedom front. and if we
> want to continue making this whole "free software desktop" a viable
> concept, we will need to at some point start saying things like "no, a 5
> year old X server is not good enough" or "yes, you DO need kernel hooks to
> let us know when things are plugged into the machine" or "no, it isn't ok
> to have N event loop implementations because that's just stupid" or "here's
> a way to get your app to use our file dialog (and vice versa) and everyone
> should use it"
I had been always advocate of regulated freedom. Without any kind of 
regulation freedom becomes nuisance as this case shows.
When I was thinking about why windows is ahead from linux in desktop, the 
first and foremost thing, which struck to me was the diversity of linux 
desktops, which makes it impossible to have coherent desktop services.

I envision a day, when there would desktop GUI controls services just like 
Windows Activex Controls,OLE and related services, which the developers would 
just be able to embed in any widget. Currently within KDE, there are numerous 
services which is at par with these things. But really how many application 
can use them, unless they are pure KDE application?
Certainly we would require some day kernel hooks .We should see how windows 
gives graphical notification for even the lowest level(kernel) events.
What I suggest is that we can have EventLoop and other goodies of core 
libraries things implementation in a separate library. And both desktop would 
use them. 
In fact, Trolltech can create the separate library on its own and then it 
would become glib's responsibility to implement that. Just like we are now 
going to utilize DBUS which was created mainly by gnome guys.

Vinay Khaitan