Prepping KDirModel and KFileItem for QML

[Mark]

Hi,

In my project i need to use the KDirModel and KFileItem
functionalities. KDirModel is exposed through the custom class that
Marco Martin made [1] and it works. However, that custom class does
(apparently) need to expose some QML ready data hence the get function
[2] (from line 99).

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

Also while doing this it made me realize that KDirModel only needs
minor changes for it to work in QML as well. Most notably are the
roles [4] that will have to be exposed to QML. That's something Marco
made a start with in DirModel and i made it more complete in my
version [5].

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

Another thing i would like to discuss is exposing things and settings.
For example, the current DirModel from both Marco and I have a
hardcoded thumbnail size (not exposed to QML). "if" that thumbnail
even belongs in the model is a question i have (i think it should be a
separate component) and even if it does belong in the model then it
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.

And what needs to be done with refresh? As the header currently stands
[3] it's all static data. Would we want refresh to be working and
change the data? In my case i don't need that functionality because i
only pull up the KFileItem data when i actually click a file.

Cheers,
Mark

[1] http://quickgit.kde.org/?p=plasma-mobile.git&a=tree&h=0be8c2064e1f1991df9196878d506de0eed688f5&hb=7ad9867427078918939f8d5a0be6201368ede63f&f=components%2Fdirmodel
[2] http://quickgit.kde.org/?p=plasma-mobile.git&a=blob&h=1539ae3d6cf54f96af216593e5c7517df820a6b8&hb=7ad9867427078918939f8d5a0be6201368ede63f&f=components%2Fdirmodel%2Fdirmodel.cpp
[3] https://gitorious.org/porpoise/master/blobs/master/fileitem.h
[4] http://api.kde.org/4.9-api/kdelibs-apidocs/kio/html/classKDirModel.html#ac91fa3775de77f10d77db06276512d47
[5] https://gitorious.org/porpoise/master/blobs/master/dirmodel.cpp#line44