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

[Alexander Neundorf]

On Friday 29 October 2004 16:33, nf wrote:
> Hi!
>
> On Fri, 2004-10-29 at 12:52, Piotr Szymanski wrote:
> > Hi,
> >
> > nf (Friday 29 of October 2004 04:32):
> > > 2) Use KIO: That would require everyone to link to a huge graphical
> > > toolkit library. Even when using the VFS from the command line...
> >
> > Or wait for qt4 by then (Q3 2005 if i remember correctly) the library
> > (libQtCore.so) will be as small as glib. I dont really feel well about
> > making KDE 100% depend on glib (an you can be sure it wont be welcomed in
> > KDE as well), making arts depend on glib only resulted in most of
> > developers moving back to an older version of arts.
>
> Would it be a compromise to move glib to fd.org and call it fd_glib?

How about moving kio to fd.o and calling it fd_kio ?
Would be a good compromise IMO ;-)
>
> I think - one day - you will have to make a decision on the hierarchy of
> technologies: Choose one technology for the tiny common back-end bits
> and others for the layer above that.
>
> Agreeing on a common back-end "technology" (fd_glib i would suggest)

AFAIK glib contains e.g. container classes and stuff.
Why should a C++ developer use C container functions ?
There is the STL and there is Qt and soon QtCore.

> doesn't say anything about the design of the common libraries. The
> design should be done by both "camps", making their VFS, component
> system or whatever compatible, picking the best concepts.

IMO the kio/vfs is maybe the most important part of all this. Getting them 
interoperable in some way would be good.

Throwing away kio or vfs won't be accepted by the respective group.


Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net