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

[nf]

On Sat, 2004-10-30 at 12:48, Allan Sandfeld Jensen wrote:
> On Saturday 30 October 2004 01:44, nf wrote:
> > On Fri, 2004-10-29 at 21:45, David Faure wrote:
> > > I really wish we'd be concentrating on writing specs here, instead of
> > > always coming up with "let's merge the world" threads that lead nowhere.
> >
> > The sad thing is that its not technical reasons why discussions about
> > merging things "lead nowhere".
> >
> Yes there are. The common argument from KDE developers for not liking C 
> libraries is because of the inferior APIs these libraries often have. You 
> will never get KDE developers to give up clean nice APIs and move to C APIs, 
> and you will never get GNOME developers to move to move to a feature-bloated 
> (API is king) language like C++. 

I feel a bit misunderstood. Linking to C libraries in the background
does not mean that any KDE developer has to deal with C-APIs. They will
still be able to use their nice KIO or whatever API. Writing C++ to C
wrappers or the other way round is no technical problem. It happens all
the time.

Maybe some people got so wound up about my fd_glib proposal because they
misunderstood me. I see glib just as a convenience library for C
programming which allows to write C programs more easily than just
coding with POSIX & LIBC. And if someone decides to write a common
library in C using fd_glib (hidden by beautiful KDE wrappers of course)
if think that should be perfectly acceptable to everyone.

I think one decision which could really boost desktop and application
integration is about the common main loop. It would help all desktop
environments to become more successful. The problem is that if it turns
out that glib has the most generic and sophisticated main loop and
signal&slot library and it would be really easy to plug Qt into it,
we'll sure get another flame war. That's why i came up with the proposal
for glib (or parts of it) to become a fd.o "commodity".

The reason why i think that this common standard library issue is
important, is that writing specs is just not enough for lots of things.
Integration has to be pushed to a higher level to make the free desktop
"just work". A common VFS for instance needs a high performance
"service" style system, which means you need common code not specs. And
someone already said that DBUS does not fit for this purpose.

An i think it would be no problem at all to write C-wrappers for
Qt-based C++ libraries. Like plugging KIO slaves into a common VFS.
A license change of QtCore would probably help a bit. So please
Trolltech change the License of QtCore to LGPL. That would really help
to get it more widely accepted. And you can keep GPL for the rest of Qt.
I have no problem with that.

Norbert