Prepping KDirModel and KFileItem for QML

[Kevin Krammer]

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.

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.

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

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20121117/9267630b/attachment.sig>