Prepping KDirModel and KFileItem for QML

[Kevin Krammer]

On Saturday, 2012-11-17, Mark wrote:
> 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.

Merging the changes as in adding Q_PROPERTY to KFileItem is not possible due 
to KFileItem not being a QObject and Q_PROPERTY requiring a QObject subclass.

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

You probably meant 4.11

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

Actually I would go for a more fine grained namespacing, after all we are 
trying to move aware from "libs" as a single entity with the KDE Frameworks 5 
effort.
Since both classes discussed here are in kdelibs/kio, maybe something more 
along the lines of "org.kde.kio"

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/841bb23e/attachment.sig>