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