Re: Moving Baloo and Baloo-widgets into KDE SC
On Tue, Dec 24, 2013 at 11:32 PM, Thomas Lübking thomas.luebk...@gmail.com wrote: On Dienstag, 24. Dezember 2013 22:03:28 CEST, Àlex Fiestas wrote: On Tuesday 24 December 2013 21:25:37 Ivan Čukić wrote: The point is, that you virtually cannot make a release that breaks half the former nepomuk clients. You'd get thousands of bug reports about feature x in application y broken/not available all over the place. ... but in general we stick with nepomuk until P-W/2. 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. Waiting for Plasma 2 will still result in exactly the same situation that you want to avoid. Some apps wanting to use nepomuk others using baloo. That will either result in some apps not having all their functionality or having two indexers/data stores which is also bad. 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. This is not about the quality or sheer sanity advance of Baloo, but the bare necessities (yes ;-) of release management. Albert will unleash Shir Khan if we f*** the (for workspace: minor) release - or just revert breaking commits =) The point of the rules is to make sure we don't break the user experience worse, and they are good rules with good reason. However, if the rules prevent us from making the user experience in general better then we should allow exceptions. David
Re: Moving Baloo and Baloo-widgets into KDE SC
Vishesh, Review of the folder core itemtype.h is useless. - it is not namespaced and it doesn't do anything. datastore.h - it's public, so should use a d-pointer. query.cpp - you don't delete d ? - there's a few things still TODO result.h does it make sense to use Baloo::Item::Id instead of QByteArray? term.h why have isNegated() and negated() they appear to be identical. Will review other folders throughout the week.
Re: Moving Baloo and Baloo-widgets into KDE SC
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á) Cheers, Thomas
Klook/dolphin
Is anybody still working on Klook? If so I have an updated patch for dolphin integration. signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Wed, Dec 25, 2013 at 10:15 PM, Thomas Lübking thomas.luebk...@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
Re: Moving Baloo and Baloo-widgets into KDE SC
El Dimarts, 24 de desembre de 2013, a les 11:28:11, Vishesh Handa va escriure: Hey guys I would like to move Baloo and Baloo-widgets into KDE SC soon. It would be nice if someone could review the code. Both the projects are in kdereview. The pim agent Messages.sh catalog name is wrong as discussed on IRC. balooshow and baloosearch are missing Messages.sh kio_tags is duplicated. What's the plan for it? Kill the old one? In that case, can the new one search tags created in nepomuk? Same question for kio_timeline. I'm also concerned about what all the others are asking. In an ideal world the user should not care if he's using an app that uses baloo or uses nepomuk, since, as far as i understand, the user exposed functionality will be the same (even if the inner stuff is different), so if previously i did a tag somewhere and it showed somewhere else, i'd still expect this to work even if the stuff is using different backends. As far as I understand, that's virtually impossible, but then it leads to the question. What's the plan? Just port *all* of nepomuk uses over to baloo for 4.13? What about the uses in kde-workspace? Cheers, Albert Baloo is a metadata and search framework which is a successor to the Nepomuk project. It primarily provides - * An API for searching * A way of storing relations between entities * File indexing * Email and Contact Indexing * timeline kioslave Baloo-widgets is a direct fork of nepomuk-widgets (history preserved). It offers the same widgets and API as nepomuk-widgets.
Re: Moving Baloo and Baloo-widgets into KDE SC
El Dimarts, 24 de desembre de 2013, a les 11:28:11, Vishesh Handa va escriure: Hey guys I would like to move Baloo and Baloo-widgets into KDE SC soon. It would be nice if someone could review the code. Both the projects are in kdereview. baloo-widgets does not load it's catalog message anywhere. Please use a KCatalogLoader (and while at it fix it for nepomuk-widgets too :D) Cheers, Albert Baloo is a metadata and search framework which is a successor to the Nepomuk project. It primarily provides - * An API for searching * A way of storing relations between entities * File indexing * Email and Contact Indexing * timeline kioslave Baloo-widgets is a direct fork of nepomuk-widgets (history preserved). It offers the same widgets and API as nepomuk-widgets.
