Prepping KDirModel and KFileItem for QML

[Mark]

On Mon, Nov 19, 2012 at 7:00 PM, David Faure <faure+bluesystems at kde.org> wrote:
> 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.

That... is one awesome example :)
Thank you for being so clear.
>
>> >> >> 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
>

I think i have a clear picture now of what needs to happen now.

1. Add rolenames to KDirModel. (only change in kdelibs)
2. Add a "org.kde.kio" QML Import to kde-runtime
3. in org.kde.kio, add a "FileItem" which exposes functionality of
KFileItem. Not as a QDeclerativeItem, just as a class inheriting
QObject.
4. in org.kde.kio, add a KDirModel subclass (DirModel) and add a
indexForItem that returns a FileItem object. (this is a
QDeclerativeItem)

The above is about the same as i have right now only nicer :)

@David, is there anything else to further improve this in the frameworks?