Prepping KDirModel and KFileItem for QML

[David Faure]

On Saturday 17 November 2012 18:02:59 Mark wrote:
> On Sat, Nov 17, 2012 at 5:04 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> > On Saturday, November 17, 2012 16:22:07 Mark wrote:
> >> Why don't we just make KFileItem available in QML.
> >> It doesn't have to be a QML component, but if KFileItem where to have
> >> Q_PROPERTY lines then most of the data would already be possible to
> >> make available
> > 
> > because this means making KFileItem a QObject, which makes it non-copyable
> > and brings in QObject overhead that we don't need.
> 
> Ahh right. So it has to be a subclass.

No, it should probably be a QObject that owns a KFileItem, as Kevin Krammer 
said.

Inheriting from a value class is like having "class Customer : public QString" 
-- you wouldn't write that...

> > Yes, it would be rather nice if all models in kdelibs that are sensibly
> > usable from QML set roles.
> 
> Yeah. Would a patch for that be accepted in KDE 4.11?

I don't have an issue with adding a few trivial roles to KDirModel, but 
anything bigger sounds like KF5 material.

> >> What i want to do is discuss these changes that Marco and I have made
> >> and merge them back in kdelibs 4.10 branch in KDirModel and KFileItem.
> > 
> > this is frameworks stuff.
> 
> .. can it be 4.11? I don't want to wait on frameworks 

Oh come on. Why does everyone "wait on frameworks"? Do you think it will 
happen all by itself, magically?

There's 10000 people who expressed interest in frameworks, and 3 actually 
doing some work on it. See the issue? This waiting will go on for a very long 
time, if people don't start to actually get involved and make it happen.

> I quite like Kevin' suggestion for "org.kde.kio". That's nicely
> grouped and sensible.

Yes, the framework will be called kio.

> Yes, the model does that, but KFI itself "seems" to have functionality
> for it as well. Why else would it have a refresh function. [1]

... so that the model can call it?
You seem to assume it's two different functionalities, when in fact it's the 
same.

OK, to make this more confusing: there are actually two functionalities, but 
not the ones you think.

1) if KDirNotify (a bunch of DBus signals emitted by high-level KIO jobs and 
file managers) says something changed in a given directory, KDirLister re-lists 
it and updates the KFileItems from the corresponding entry of the new KIO 
directory listing.

2) if KDirWatch (local-files change notification e.g. via inotify) says 
something changed for a given file (permissions, size...), KDirLister calls 
refresh() on the corresponding item, to update its information directly from 
the disk.

In general, there is little reason for the apps themselves to call refresh on 
a KFileItem, *if* that fileitem is being used in KDirLister/KDirModel.
On a standalone KFileItem it makes sense, of course.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5