Moving Baloo and Baloo-widgets into KDE SC

[David Edmundson]

On Wed, Dec 25, 2013 at 10:15 PM, Thomas Lübking
<thomas.luebking at gmail.com> wrote:
> On Mittwoch, 25. Dezember 2013 21:06:56 CEST, David Edmundson wrote:
>
>> With the planned slow transition of apps from kdelibs4 to frameworks
>> we are going to have a point where we have apps on either side.
>> I expect Dolphin to port very soon, KMail isn't planned for a long
>> time as KDE PIM libs are to be split.
>
>
> So you're saying KMail will have broken/no semantic desktop support for
> about a year or so....

No. There are Baloo branches of Dolphin and KDE PIM ready for merge.
I use them already.

If we didn't merge both of those then there would be no point in
trying to do this.
Most other nepomuk users (Gwenview etc) are via nepomuk-widgets, which
will be a nice and easy port.


>
> Are you somehow *trying* to get bad press? :-P
>
>
>
>> Waiting for Plasma 2 will still result in exactly the same situation
>> that you want to avoid.
>
> Yes, but no.
>
> Unported (kdelibs4) apps will be "foreigners" in a frameworks environment -
> it's expectable for them to be not fully functional.

As I understand it, that is not the plan.

Workspace intended to release ahead of applications and we are aiming
to make that seamless rather than do everything in one go.
KDE4 apps in Plasma2 are meant to be seamless without anything breaking.

> Though, if you prospect eg. KDE PIM to remain operating on (non operative..)
> nepomuk for a long time even after P-W/2 release, some wrapper seems
> inevitable anyway.
> Users can continue to use KDE4 until at least their showstopper
> kdelibs4/nepomuk client has been ported.
>
> If you however "break" things in KDE4 branch, users will have to stop
> updating (and will also not use baloo because of that...) KDE4, which would
> effectively be dropped into unmaintained mode (at least if you care about
> semantic desktop support in an unported client)
>
> So unless nepomuk is considered broken so badly that nobody uses it anyway,
> you can expect a whole bunch of regression complaints.
>
>
>
>> IMHO the safest course of action is to port everything to baloo before
>> they start being frozen for moving KF5. Then we can have kdelibs4 and
>> KF5 apps both using baloo without any runtime problems.
>
>
> "If everything is ported then everything can use baloo w/o runtime problems"
> ...
> But the problem is the transition time and whether it's visible to users,
> not the time when everything is ported.
>
> What about adding hybrid runtime support, ie. check whether baloo is
> running, if not, check whether nepomuk is running and use the resp.
> API/functionality (or none if neither is), ie. keep backward compatibility
> in ported clients and allow users to keep a virtuoso tainted but working
> setup on nepomuk or decide to drop that and rely on baloo (because they
> don't care about kmail/nepomuk because they use trojitá)
>
> Cheers,
> Thomas