Prepping KDirModel and KFileItem for QML

[David Faure]

On Monday 19 November 2012 18:11:06 Mark wrote:
> 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.

They shouldn't be :)

You usually don't want to provide the same API as a value class, in something 
that is not a value class. You found a perfect example of why: because you 
want to emit signals from setters, which the value class doesn't do.

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

No you don't really get the point.
This was a desperate plea for more people to actually make KDE Frameworks 
happen... the only valid answer is "right, I'll check it out and help".

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

This depends on how intrusive the change ends up being. From the rest of this 
discussion, QML integration for KDirModel definitely feels like a large 
feature.

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

Yes.

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

I would actually consider having a KDirModel subclass for better integration 
with QML, if new API has to be added. This will keep the C++ class clean, 
rather than having public methods that make no sense in the C++ world.

In addition, the QObject-wrapper for file items and the KDirModel subclass that 
returns these wrappers, sound like something for a libkiogui to me, while 
KFileItem and KDirLister are kiocore (but ok, KDirModel is kiogui too, since 
it handles icons and previews). Still, I'd rather see the QML support 
separated from KDirModel, just like Qt has different model classes internally 
for the declarative stuff.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Sponsored by BlueSystems and KDAB to work on KDE Frameworks