Prepping KDirModel and KFileItem for QML

[Mark]

On Sat, Nov 17, 2012 at 5:04 PM, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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.

Ahh right. So it has to be a subclass.
>
> for QML, accessing the relevant data via the model is probably the easiest
> approach anyways ...

Not really. Not all data from KFileItem is stored in the Model. You
can see it at the roles that i'm setting. That all data that is
stored. There is a lot more. I guess this depends on style:
1. Add more data to the model thus a "QMLized KFileItem" is not needed anymore.
2. Let the roles be as they are and use a "QMLized KFileItem" for file details.

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

Yeah. Would a patch for that be accepted in KDE 4.11?
>
>> 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.
.. can it be 4.11? I don't want to wait on frameworks and if it has to
be in there i probably have to keep local copies like i have now.
Besides, it doesn't add new features - not exactly. It only makes
functionality available and in this case we're talking about setting
the roles for the models so QML can use it.
>
>> 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.

I quite like Kevin' suggestion for "org.kde.kio". That's nicely
grouped and sensible.
>
>> 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.

Well, now you're getting "slightly odd" things in your model class. It
makes and maintains a KImageCache, creates the actual thumbnails and
puts it on a pixmap. In my opinion that is functionality that has
nothing to do with a model and should be separated out in it's own
class. Something like a "KThumbnail" or "KPreview" which is then also
exposed to QML.
>
>> 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 ... ?

Yes, the model does that, but KFI itself "seems" to have functionality
for it as well. Why else would it have a refresh function. [1]
>
> --
> Aaron J. Seigo

@Kevin, yes, i meant 4.11 :)

Cheers,
Mark

[1] http://api.kde.org/4.9-api/kdelibs-apidocs/kio/html/classKFileItem.html#afcd50458f3068076a1101c5b6a3b140a