Qt->glib main event loop patch (common main loop)
vkhaitan at gmail.com
Mon Nov 14 23:08:12 GMT 2005
> 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
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.
More information about the kde-core-devel