Prepping KDirModel and KFileItem for QML

[Mark]

On Sat, Nov 17, 2012 at 4:40 PM, Kevin Krammer <krammer at kde.org> wrote:
> Hi Mark,
>
> On Saturday, 2012-11-17, Mark wrote:
>
>> So i was thinking: 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. I did this in my code and it works rather nice though
>> i inherited KFileItem as "FileItem". It's a header only class [3].
>
> It might not be necessary to subclass KFileItem (unless you need access to
> protected API), a QObject class holding a KFileItem might do as well.

Well, i made a subclass because there are not much other ways to do
the same outside of kdelibs. The intention is obviously to merge my
changes back in KFileItem and not subclass it there.
>
> The latter obviously having the advantage that the contained KFI instance's
> setters are not exposed, thus guaranteeing that all changes must go through
> the QML adaptor's setters, thus making sure proper change notification signals
> being emitted.
>
>> 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.
>
> I believe that the 4.10 branch of all modules is frozen at this point.

That's oke. I don't expect this to be done today or this week. Just
"sometime" when 4.10 is open would be fine imho.
>
>> Then KDirModel (not KFileItem) still has to be made available in QML.
>> I want to do that in either org.kde.plasma.core or introduce a new
>> import for kdelibs components and name that: "org.kde.libs" or
>> something along those lines. The latter one has my preference since it
>> really doesn't belong in plasma.
>
> I agree. I think we need to come up with a scheme and policy on how to handle
> "QML bindings" across our modules in a consistent way.

"org.kde.libs" sounds very sensible to me :) At least for "kdelibs"
functionality that is exposed to QML.
>
>> should be a settable property. Perhaps with a default value. Last
>> thing is what about the properties of KFileItem that are not directly
>> exposable to QML. Non exposable functions:
>> - ACL() (due to KACL not being available in QML)
>> - assign(KFileItem) (possible, but would we want that?)
>> - cmp(KFileItem) (possible, but would we want that?)
>> - determineMimeType() (due to return type not being available in QML)
>> - entry() (due to return type not being available in QML)
>> - extraData() (ehh..?)
>> - ... and a bunch of others.
>
> Some of those, e.g. extraData(), are marked as deprecated, so it wouldn't make
> any sense anyway to expose them in new binding API.
>
> Cheers,
> Kevin
> --
> Kevin Krammer, KDE developer, xdg-utils developer
> KDE user support, developer mentoring

Cheers,
Mark