KIO->GnomeVFS bridge started (looking for a Common-VFS)

Jason Keirstead jason at keirstead.org
Tue Dec 21 18:49:17 GMT 2004


On Tuesday 21 December 2004 1:24 pm, nf wrote:
> 3) Gnome libraries are modular from design. They almost seem to be
> designed with having the "common" usage in mind. Usually there is no GUI
> stuff inside them. KDE libraries traditionally seem to be more designed
> to serve a single desktop and come as one big block - the core for the
> KDE desktop. The frontend of KIO has GUI stuff inside for instance.
> Gnome-VFS doesn't.

This also leads to a big downfall of Gnome / Gtk IMO - because everything is 
so modular, you end up with very inconsistent apps. 

Even though there are things like the Gnome HIG, Gnome / Gtk apps are far less 
consistant in their UI than KDE ones. The IO slave stuff is a perfect 
example. KIO slaves have GUi code in them for one reason - so that, in every 
possible usage, you get the same file and progress dialogs.

This is not true in Gnome - not by a longshot. Depending on the app, you could 
get any one of 3 or 4 GTK file selection dialogs, and any one of two or three 
progress dialogs (that is, if the GVFS slaves are even available in the Gnome 
application / the application even shows progress dialogs. Frequently they 
are not / it does not.)

KDE always strives for integration, and this is what I love about it. If I 
have to suffer some modularity of the libraries in order for my apps to be 
more consistent and well integrated, so be it - that is a sacrifice I will 
make.

> I think using KIOSlave code inside Gnome-VFS is definitely a good idea.
> But i would not use them as they are, but rather write a C++ porting
> layer on top of the Gnome-VFS modules concept which almost acts like the
> SlaveBase class, but without Qt stuff inside. Porting them should be
> possible, because the Qt bindings of io-slaves are not very strong.

Why would you want take the existing KDE code, write a porting layer, and move 
it to GVFS? (and then, I assume, port KIO to use GVFS?) All you are doing is 
introducing additional code paths and potential bugs in the slaves.

If you re-implement the KIO IPC mechanism for GVFS, you have no new code 
paths, the slaves are the exact same, and you can debug the IPC independently 
of the slaves. Also, any new KIO slaves will instantly work without any 
porting or re-compiling. Less risk, more reward.

-- 
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
    - Sun Tzu




More information about the kde-core-devel mailing list