Dolphin and Baloo

[Frank Reininghaus]

Hi Vishesh,

2013/12/17 Vishesh Handa:
> Hey Frank
>
> On Tuesday 17 Dec 2013 10:59:12 Frank Reininghaus wrote:
>>
>> I think that migrating is fine as long as it does not cause trouble
>> for the people who try to build, package, or use Dolphin. I'd like to
>> avoid things like
>>
>> #ifdef HAVE_BALOO
>> #else
>> #ifdef HAVE_NEPOMUK
>>
>> So I'd say that if we migrate, we should drop support for the
>> deprecated Nepomuk stuff completely.
>
> +1
>
>>
>> Some more questions:
>>
>> 1. Is Baloo going to be part of future KDE SC releases, just like
>> nepomuk-core and nepomuk-widgets are now?
>
> Yes. I'm going to put them up for review next week, and they should move out
> of playground in about 3 weeks.
>
>>
>> 2. Are there any changes in the API for the functionality that is used
>> by Dolphin, i.e. the meta data widget, the search/timeline stuff, and
>> the parts that are being used by the KFileItemModelRolesUpdater class?
>>
>
> - The FileMetadataWidget is going to be identical.
> - The timeline kioslave's interface is the same
> - the search kioslave has changed, but that should not affect Dolphin

sounds good.

> Things that will need to be changed in Dolphin -
>
> 1. PlacesItemModel - done
>
> 2. Searching
>     2.1 - Normal file search - done (almost)
>     2.2 - Faceted search
>
> 3. NepomukRolesProviders will be removed and a BalooRolesProvider is required.
> This is a little hard as the RoleProviders are supposed to synchronous. Baloo
> only has async APIs. I could call KJob::exec() but I do not that would be
> wise.

I think that we should better make use of the async API directly then.
I would prefer to avoid KJob::exec() because this function sets up a
nested event loop AFAIK, and I've seen too much trouble that was
caused by nested event loops already ;-)

KFileItemModelRolesUpdater already has some support for counting the
items inside subfolders asynchronously (at least if we are not sorting
"by size"). Maybe we could do something similar for the interaction
with Baloo.

It seems that the different required changes are mostly independent,
right? Are Nepomuk and Baloo co-installable? If the answer to both
questions is 'yes', then the porting could be done step-by-step.
Having both HAVE_NEPOMUK and HAVE_BALOO temporarily in the master
branch is probably not a big problem, but the HAVE_NEPOMUKs should be
gone before the next stable branch is forked from master.

Regards,
Frank