On Saturday, November 17, 2012 16:22:07 Mark wrote: > 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
because this means making KFileItem a QObject, which makes it non-copyable and brings in QObject overhead that we don't need. for QML, accessing the relevant data via the model is probably the easiest approach anyways ... > 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 Yes, it would be rather nice if all models in kdelibs that are sensibly usable from QML set roles. > 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. this is frameworks stuff. > 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. probably not "org.kde.libs" .. it's just begging to become a drop zone for random and unrelated $STUFF. org.kde.dirmodel or org.kde.filesystem would be good enough in this case? as is happening with frameworks, these things should be thoughtfully grouped into sensible modules. > 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) why a separate component? i agree that it should (if it isn't already) be both lazy-loaded and able to be disabled via a property (so usage where this is not needed avoids the overhead) ... but do we really need a completely separate component for this? i would expect a fair amount of data duplication if it were, though some spelunking in the code may show otherwise. > and even if it does belong in the model then it > should be a settable property. > Perhaps with a default value. yes, the size should be setable with a sensible default. > 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. you mean updating the KFI when the on-disk file changes? i would hope the model itself already does that ... ? -- Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.