Prepping KDirModel and KFileItem for QML

[Aaron J. Seigo]

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