KWIG Qt->Gtk porting layer and merging main loops.

nf nf2 at
Fri Oct 29 02:09:46 EEST 2004

On Wed, 2004-10-27 at 19:23, Avery Pennarun wrote:
> On Wed, Oct 27, 2004 at 06:57:21PM +0200, nf wrote:
> > KWIQ Qt adaptation layer:
> > 
> > I'm just curious. Don't you think that such a "common main loop" would
> > help to avoid lots of code duplication and improve (free)desktop
> > interoperability? Maybe a little expert discussion could inspire someone
> > to play with this...
> Common mainloops are a wonderful thing that we should definitely have.  With
> WvStreams and UniConf, we've done a bit of hackery to make this sort of
> thing work (make the WvStreams/UniConf stuff all work asynchronously without
> threads in your favourite mainloop, be it WvStreams, Qt, glib, or win32). 
> If we can manage to agree on a common standard, that would be perfect.  I
> think libevent should be that standard.  Just grab it and use it; it's the
> basic model that everything else is based on anyway.  I'm pretty sure glib's
> mainloop stuff is sufficiently flexible that you can probably do this pretty
> transparently.  Qt, I'm not so sure.  Something about QSocketNotifier.
> Combining the signals/slots mechanisms between Qt and GTK sounds messy and
> scary, but simply running *both* signals/slots mechanisms on top of libevent
> should be pretty straightforward.

I just found a project called QtGtk.

Quote from the documentation:
"The basic goals of the whole undertaking were: make is incredibly
simple to integrate Qt event loop into a GTK+ application"... "We
achieved those goals with a trivial implementation of a GSource which
integrates Qt event loop into Glib event loop"



The documentation says that QtGtk can help migrating GTK+ applications
to KDE. 

I wonder if QtGtk could be used the other way round - to use glib-based
infrastructure like GNOME-VFS from KDE ;-) 

This makes more sense to me, because using kde-libraries as common
infrastructure would require all desktop applications to be GPLed
(linking to Qt). 



More information about the xdg mailing list