KDE is not an OS platform... (And neither is Gnome)

nf2 nf2.email at gmail.com
Tue Nov 3 23:23:04 GMT 2009


On Tue, Nov 3, 2009 at 2:43 AM, Aaron J. Seigo <aseigo at kde.org> wrote:
> On November 2, 2009, nf2 wrote:
>> * Change Konq to just download such files, just like FF. Personally i
>> like that web-browsers are kind of their own sandbox, not sharing
>> session information with the rest of the computer. For instance I'm
>> using two browsers on my desktop: One for Gmail, and one for everthing
>> else. But i can hear the KDE crowd shout: That's against our credo - a
>> fully integrated desktop.
>
> as Will noted, you are indeed fighting against the current here and we are
> simply not interested in taking steps backwards in the user experience just to
> win a phyrric victory that lets us say "we share a VFS layer".

This highly integrated desktop is also a kind of phyrric victory. At
least where it crosses the path of basic application infrastructure
(which KIO is certainly about). As it's sort of assuming a platform
where there isn't one.

However,

* ftp
* sftp
* smb
* nfs
* fish
* dav
* network
* archives (zib, tar, iso,...)
* bluetooth
* cdda
* camera

Those protocols aren't that intervoven. Therefore it should be easier
to get them into a more "platformy" layer.

This should improve the unlucky relationship which KIO currently has
with those protocols:

* Those users which can be satisfied with a pure KDE desktop (KDE apps
only), probably don't need to work with file-servers a lot.

* And those users who need that feature, can't use KIO, because they
are running a very heterogenous application base.


>
> all is not lost, however. as i've mentioned numerous times in discussions on
> IRC there are several related places we can work on broad integration that
> have NONE of the complexity or downside implications of a "Grand Unified VFS
> Layer" have. this includes things like a shared wallet system, a shared
> cookies storage system, a shared "places" system, etc. those things which are
> not yet standardized and do cause REAL issues with the user experience today.


What worries me, is that there isn't even a plan for the VFS layer.
Because getting there definitely has quite a lead time.

* If GVFS turns out to be the solution (unfortunately nobody else has
evaluated it), then it can't adjust to that instanly. Like making URLs
of certain protocols QUrl compatible, getting rid of a little gconf
dependency, and perhaps fixing other little glitches we don't even
know about...

* 3rd party apps and toolkits also need time to adopt an VFS layer. Qt
in particular, because it lacks an async file-IO API.

So what i'm saying: This doesn't have to happen tomorrow, but there
needs to be a plan. Not deciding means wasting many years...

So my propsal is: Lets try to do a GVFS port, including the places
model, just enabled when KDE apps are running on Gnome. Then we get a
clearer picture how well that works and where the problems are.


Norbert




More information about the kde-core-devel mailing list