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
