Common main loop: Qt ported to glib main loop (experimental)

[nf]

Hi!

On Fri, 2004-12-03 at 17:03, Alexander Neundorf wrote:
> On Friday 03 December 2004 16:49, nf wrote:
> ...
> > Of course it has Qt-dependencies. Qt is almost like a C++ dialect (with
> > the signals and slots stuff) - so it's used in all KDE libraries. As i
> > said before: That wouldn't be a problem if the core (non-Gui) parts of
> > Qt were LGPLed.
> 
> For this specific point it doesn't really matter whether it's GPL or LGPL. I 
> mean, we are talking about the ioslaves, apps don't link to them, they talk 
> via a pipe. Nothing hinders anybody (license-wise) from writing a non-free 
> application, let's say with gtk, which is able to talk to GPL'd ioslaves.

True - i was thinking in a more general sense. And every VFS also needs
an "in-process" part.

> 
> ...
> > 3) We choose GNOME-VFS and steal ideas from KIO.
> 
> Dumping the existing solution of one project in order to go for the solution 
> of the other project won't work. No matter in which direction.

If you have two libraries and you only need one then you have to throw
away the other. Well - you could write a third one - then you have to
dump two. But people would ask you if you are stupid then.

I know that dumping things hurts, but it's the consequence of not
developing a common VFS years ago. I think every day KDE and GNOME
developers continue improving KIO or GNOME-VFS makes things worse.
Someone has to pull the emergency break. And that applies to a lot of
those duplicated libraries.

Of course you could standardize all kind of strange workarounds to make
two libraries act like one. But what's the value of that, except bloat?

> 
> > 4) We take a hammer and hammer GNOME-VFS into kdelibs to completely
> > replace KIO. 
> 
> There is a practical problem. Who do you think will be able to take a hammer 
> and hammer something into the kde core libraries ?

With the "hammering" i meant a very experimental approach. And GNOME-VFS
would get a bit deformed as well (adding features, learning from KIO). A
Common-VFS certainly won't go into the production code-base right from
the beginning. So - yes - it would be a temporary fork. Who can do that?
There are people who achieve things like this:

http://dot.kde.org/1101482981/ (OpenOffice.org 1.1.3-kde)

Excellent work, but heading in the wrong direction (IMHO). Porting
forever. In the long run consuming a lot more energy than merging some
relatively small bits at the basis, thats for sure...

Maybe i am naive.

Cheers,

Norbert