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

[nf]

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: http://gtk-webcore.sourceforge.net/
> > 
> > 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"

Tutorial:
http://developer.kde.org/documentation/tutorials/qtgtk/main.html

Files:
ftp://ftp.kde.org/pub/kde/unstable/apps/KDE3.x/utils/qtgtk-0.1.0.tar.gz
http://groups.google.com/groups?q=qtgtk+bugfix

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). 

Regards

Norbert