Baloo File API Changes

[Emmanuel Pescosta]

> Perhaps you could give some input?

UserMetaData::isSupported should be a static method with a file path
parameter I think

I would remove UserMetaData::addTags and UserMetaData::removeTags
because you can achieve the same with tags + setTags. It is also
easier to implement when you are using tags/setTags rather than
addTags/removeTags because you can use the tags as a model, modify it
and set all tags again when the user applies the changes. When you
want to use addTags/removeTags you need to keep track of what tags
were added/removed. AddTag/removeTag makes sense.

Maybe "user." instead of "user" in
UserMetaData::setAttribute/UserMetaData::hasAttribute?

I would return success/failure in all setter/modifier methods (like
setTags, ...) or maybe (better) throw exceptions when the
reading/writing failed?

In UserMetaData::addTag() and UserMetaData::removeTag():Maybe a simple
QList:contains/QList::removeOne would be better (has O(n) but you can
eliminate the list->set->list conversions)

KFileMetaData Type enum -> enum class?



Have a nice weekend!

Cheers,

Emmanuel


2014-10-14 12:56 GMT+02:00 Vishesh Handa <me at vhanda.in>:

>
>
> On Tue, Oct 14, 2014 at 10:14 AM, Emmanuel Pescosta <
> emmanuelpescosta099 at gmail.com> wrote:
>
>> Hi Vishesh,
>>
>> >  You cannot modify anything.
>> > Baloo::FileModifyJob is no more.
>>
>> Hmm, so we can't implement tagging via context menu or interactive rating
>> in the view for example? (I'm looking forward to some possible features in
>> a Dolphin qml/qtquick world ;)
>>
>> Will the UserMetaData class be public/exported, so we can use it instead
>> of the modify job?
>>
>
> Yup.
>
> Baloo is also going to be using the same API to fetching the
> tags/rating/comments in order to index them. Baloo-widgets is using it for
> setting the tags. The API is synchronous since it is mostly a Qt wrapper on
> top of system calls. The initial draft of the API has been published for
> 5.1 in KFileMetaData. Perhaps you could give some input?
>
>
>>
>> > From a Dolphin point of view, a synchronous API isn't that bad since
>> this was only being called for one file at a time.
>>
>> I think we should change one file at a time to a batch of files in the
>> future.
>>
>> The synchronous API is ok for Dolphin.
>> I want to change the additional info fetching in future anyway (needs
>> some time because I will do some experiments first and talk to other
>> Dolphin devs about my idea) - with threading support and one interface for
>> everything (version control, cloud sync, baloo, directory size det. and
>> other role providers).
>>
>
> Sounds good.
>
> Currently the Baloo::File class has a load() function which would block
> for a short amount of time, depending on how slow your disk is.
>
>
>> > I would like to split that into usermetadataroleprovider and
>> balooroleprovider.
>>
>> Sounds good, a perfect use case for my idea ;)
>>
>
> Cool.
>
> Then, I'll start polishing up the branch and submit review requests for
> Dolphin.
>
>
>> Cheers,
>> emmanuel
>>
>>
> --
> Vishesh Handa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20141017/a9decdd3/attachment.htm>