[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE is not an OS platform... (And neither is Gnome)
From:       David Faure <faure () kde ! org>
Date:       2009-11-04 0:14:58
Message-ID: 200911040114.59196.faure () kde ! org
[Download RAW message or body]

On Wednesday 04 November 2009, Christoph Feck wrote:
> On Wednesday 04 November 2009 00:23:04 nf2 wrote:
> > Qt in particular, because it lacks an async file-IO API.
> 
> QIODevice (the class which QFile inherits from) is asynchronous,
> at least API-wise.

But only API wise.
QFile doesn't emit readyRead like a socket does. It just doesn't make sense
in the "common case" (local files).
Do we really want to port every QFile usage to be socket-like code,
with signals and slots?

The way it is right now is quite clear and simple. We use QFile when we are 
working with files that we know to be local. KConfig files, desktop files, 
bookmarks file, app-specific data files in kdehome, etc. Anything out of 
KStandardDirs, basically. For everything else, i.e. for user-specific files, we 
use KUrl and KIO. Different API, different behavior, and for a very good reason: 
because these are remote, therefore potentially slow, therefore you need to go 
back to the event loop i.e. do it all asynchronously. You can't fix every 
problem in the house with a hammer :-)

What do we gain, API wise, from having a QFile that emits readyRead(), 
compared to a KIO::TransferJob that emits data()? I just don't get it.
It doesn't help KDE apps, and it doesn't help non-Qt apps, so it only helps 
Qt-only apps!? I don't think this is what this discussion was about,
since Qt-only apps represent only a little piece of a unified VFS dream.

-- 
David Faure, faure@kde.org, http://www.davidfaure.fr
Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org).
[prev in list] [next in list] [prev in thread] [next in thread]