Moving Baloo and Baloo-widgets into KDE SC

Thomas Lübking thomas.luebking at
Wed Dec 25 21:15:37 GMT 2013

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

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


More information about the kde-core-devel mailing list