Prepping KDirModel and KFileItem for QML

[Mark]

On Mon, Nov 19, 2012 at 12:05 PM, David Faure <faure at kde.org> wrote:
> 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...
>
Both principles are fine with me.

>> > 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.

I guess that gives me the go-ahead to put a patch in reviewboard :)
I will wait with that till there is a 4.11 branch.
>
>> >> 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?

Yeah, i get the point. But i can't imagine that this relative simple
change in KDirModel (and KFileItem) should only go in KF5 only. What
i'm proposing doesn't add features to kdelibs, it only makes existing
features usable in QML.
>
> 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.

Ahh, i get it. So the actual KFileItem can change. I guess that means
that all properties should also have a onChanged signal to notify QML
of the change.
>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE, in particular KDE Frameworks 5
>

Now i do have one last issue. If KFileItem itself is not going to
inherit from QObject then it can't be used in QML. So the KDirModel
function itemForIndex: [1] can't be called directly from QML because
the return object isn't QObject derived.

My intention is to use KDirModel directly from QML like so:

KDirModel {
    id: dirModel
    url: "/some/url"
}

Then you can iterate through it like so:
ListView {
    model: dirModel
    delegate: Text {
        text: index
    }
}

However, in this case you can't do:
dirModel.indexForItem(index) because of the return object and the
index parameter.

What's the suggested way to fix these issues? I'd like to fix them in
KDirModel itself so that there is no need to subclass KDirModel just
to add an alternative indexForItem method. But to get there the
KFileItem either has to be derived from QObject or another
indexForItem method has to be introduced that returns a class that QML
can use.


[1] http://api.kde.org/4.9-api/kdelibs-apidocs/kio/html/classKDirModel.html#a0337f0a2fdd1f6cf9db38abd13de6ca1