Re: Moving Baloo and Baloo-widgets into KDE SC
On Fri, Jan 10, 2014 at 11:02 AM, Mario Fux KDE ML kde...@unormal.orgwrote: Am Donnerstag, 09. Januar 2014, 23.26:01 schrieb Àlex Fiestas: Morning Alex On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. I have to disagree here. And I'm probably disagree with you but let me explain below. We can't keep playing this conservative when we have things that are in the Nepomuk situation. If it is the most hated piece of software we have is not by chance. If the breakage is minimal (which I know it is, but I will let vHanda reply to that) I vote to replace it even if we make a bit worse the experience using some weird application that nobody has heard of. The release schedule for 4.13 is really short (4 month). With the feature freeze in approx. 1.5 months, see [1]. As 4.13 will be one of our last release in the 4 era I think we should be quite sure that we don't break anything or even more to be 110% sure to have fallbacks, migration, APIs for Nepomuk apps to access Baloo data etc. And even though I know that Vishesh is doing a great and a hell of a job I'm not too sure if one single person can manage all of this (not just the implementation but I think it needs a lot of testing as well). IIRC it's still not clear for all the current Nepomuk apps if they work after 4.13. Let's try to list them again. - Amarok (got Nepomuk support with 2.7, will it work after 4.13? - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer - Plasma Active/Plasma mobile with Share-Like-Connect From what I read on the baloo page, it seems likes baloo accesses various databases. If that is the case, instead of a bridge that copies metadata back and forth like in nepomuk, would it be possible for programs like Digikam and Amarok to allow baloo to access their databases directly?
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 21 January 2014 12:34:52 Todd wrote: From what I read on the baloo page, it seems likes baloo accesses various databases. If that is the case, instead of a bridge that copies metadata back and forth like in nepomuk, would it be possible for programs like Digikam and Amarok to allow baloo to access their databases directly? Theoretically, yes. In terms of searching this would be very simple to do. Anyone can provide a search plugin which provides searching over different types. We currently have the following search plugins - * File * Emails * Contacts I'm going to be adding some more for Events/Calendar entries. In term of actually fetching / saving metadata, it should be possible. I just haven't figured out how. -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Sunday 19 January 2014 15:56:17 David Edmundson wrote: Code Review of baloo/file/lib ==file.cpp Should it override type() from Item and set it to File ? I'll probably removing this whole type thing. I'm not sure. ==filemodifyjob.cpp. The code won't unset a rating, comments or tags on multiple files. You update Xapian ok, but you're not calling fsetxattr(). Right. I think I'll need to re-architecture the internals. There needs to be a way to differentiate between removing the rating and the user not setting them. Eg - File f(someUrl); f.setRating(5); save f; In this case the comment and tags would be removed even though they should not. The d pointer leaks? Fixed d-pointer. ==DB.cpp SQLITE3- SQLITE Fixed. ==general Are you planning on putting all the Xapian queries in a new thread in the future? If not having a KJob API doesn't have any benefit does it? Not right now. Xapian blocks for a very very small amount. In the future if required it can be moved to another thread. I would suggest you namespace your header guards i.e #ifndef FILE_H - #ifndef BALOO_FILE_H The current ones are very generic, it will be very easy to accidentally clash. Thanks. Fixed. David David -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
Code Review of baloo/file/lib ==file.cpp Should it override type() from Item and set it to File ? ==filemodifyjob.cpp. The code won't unset a rating, comments or tags on multiple files. You update Xapian ok, but you're not calling fsetxattr(). The d pointer leaks? ==DB.cpp SQLITE3- SQLITE ==general Are you planning on putting all the Xapian queries in a new thread in the future? If not having a KJob API doesn't have any benefit does it? I would suggest you namespace your header guards i.e #ifndef FILE_H - #ifndef BALOO_FILE_H The current ones are very generic, it will be very easy to accidentally clash. David David
Re: Moving Baloo and Baloo-widgets into KDE SC
This doesn't need to be be in the first release but I would like an exposed Qt interface to fsetxattrs and xgetxattrs. Ideally this would be exposed in the File object, maybe with some sort of QVariantMap userProperties() method. FileFetchJob would then load all the properties in the same way ratings/comments/tags are now. Ratings etc. become just specially named entries in this map with convenience methods to get/set them. This is really needed in order to complete the porting of kdenlives usage where we are tagging custom attributes (license type + creator)
Re: Moving Baloo and Baloo-widgets into KDE SC
Ideally this would be exposed in the File object, maybe with some sort of QVariantMap userProperties() method. Please don't make it load all attributes and values into the memory if the most common use-case is to load a value for a desired key. I'd rather go for something like some_iterator listAttributes bool hasAttribute(prop) QWhatever attribute(prop) Cheers, Ivan -- Science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov
Re: Moving Baloo and Baloo-widgets into KDE SC
Am Freitag, 10. Januar 2014, 11.28:34 schrieb Sebastian Kügler: Hey, Morning sebas and Co Here finally my answer to this thread. [snip] - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? Is anybody of the Digikam team reading this? Or should somebody contact them? Please speak. - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer Let me point out the obvious here: We can discuss possible quality problems for a few more weeks, *OR* we use the time to actually test the code on a wider range of systems. This way we wouldn't have to guess so much about possible impact to other apps, and we can judge much better how ready Baloo is. Sometimes pointing out the obvious is not bad ;-). Of course you're right. I just had the subjective impression that it's holding back. Which changed (at least my perception of it) which is great. Don't see Baloo as a third party service that someone else has to fix and debug, rather get on the train, test it, report your experience and make it possible to get it solidly working. Ok. [snip: Plasma Active] So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. I'm not strictly against this. Actually, we have some lenience with the long term support workspace out, so we can recommend people to use that, if they're slightly more adventurous, run 4.13, if they are completely mad, help us getting Plasma 2 in shape. That's quite a nice array of options. Communicated in the right way to our downstreams, this helps us to avoid problems. This I don't get as it speaks against all I told people about all our three different releases (apps, workspaces and platform). But I think this may be a misunderstanding. So my conclusion. Let's do it asap and know and see the effects and get as many testers as possible so that we can release 4.13 with a great Nepomuk replacement or better evolution of Nepomuk. Thx Mario PS: About Jan's question if there are more applications that share KPhotoAlbum's slight use of Nepomuk. TBH I don't know.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 17 January 2014 11:54:06 Mario Fux KDE ML wrote: Am Freitag, 10. Januar 2014, 11.28:34 schrieb Sebastian Kügler: Hey, Morning sebas and Co Here finally my answer to this thread. [snip] - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? Is anybody of the Digikam team reading this? Or should somebody contact them? Please speak. I've emailed them today.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 10 Jan 2014 18:17:48 Thomas Lübking wrote: On Freitag, 10. Januar 2014 11:28:34 CEST, Sebastian Kügler wrote: with the long term support workspace out, so we can recommend people to use that, if they're slightly more adventurous, run 4.13 I'm not sure whether I understand that - afaiu there will be no workspace 4.11 ever, but other parts (baseapps) etc. proceed - and nepomuk/baloo crosses those releases. Ie. you'd tell them to - stay with workspace 4.11.x (x being the release right before the change to baloo) and nepomuk and also all other packages of that time (eg. 4.12.4), iow. simply stop updating at all or to - stay with workspace pre-baloo and only update other parts to baloo versions, what will likely create a mess in the semantic desktop stuff or to - just update as usual, accepting a potential friction (for clients/features relying on lost nepomuk) Ie. to either stop updating or be prepeared for migration trouble on the semantic desktop front. I think what Christoph wanted to say was: please don't start baloo like what ended nepomuk. Communicated in the right way My 2¢? Assuming you want to replace nepomuk by baloo in SC4: Draw a fat red line. Publically announce *now* that the sematic desktop system will get an internal update that will preserve general functionality, but is unfortunately incompatible with the present nepomuk approach. This will happen with [release here] in about [n] weeks, what implies to rather skip that particular version for productive systems - if you rely on semantic desktop features. This was decided to happen now, because KDE SC 4 will continue to be the stable KDE desktop environment for [estimated time here] and the semantic desktop either needs a major overhaul or is best not used at all, ie. the alternative would have been to schedule this for KF5 PW/2 and declare the fix for semantic desktop issues to not use a semantic desktop. I like this. How should one go about this? Dot article? There'll be migration tools, but every further KDE SC release will not provide *any* support for nepomuk anymore (beyond ABI compatibility library stubs) If you crucially rely on a clients nepomuk features, you can check [wiki url] to see whether it's already available in a baloo version - otherwise do not update KDE SC beyond that version until it is. http://community.kde.org/Baloo/NepomukPort Contrary to other suggestions i can also only recommend to ditch nepomuk as name to not leave any ambiguity. According to the reasons mentioned in this thread (most hated), the name is burned anyway, but the main reason is that ppl. talk about semantic desktop features by the term nepomuk and that will lead to confusion since (if) you cut legacy nepomuk support (nepomuk is running, but does not work in client xyz) So communicate that nepomuk (and support for it) goes, baloo comes, the semantic desktop idea stays - just without virtuoso. +1 for ditching the Nepomuk name. Publish eg. an interview with Vishesh that outlines the major differences between nepomuk and baloo and the major benefits of this change. Cheers, Thomas -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Sonntag, 12. Januar 2014 12:28:09 CEST, Vishesh Handa wrote: How should one go about this? Dot article? An article on dot will help, but it's not important where the information is hosted. What is important is that it has the character of an official press release. a) It has to show up in mainstream media (slashdot friends) *now* - not when things happened. b) It must *not* come along like KDE developer Vishesh Handa wants... but as KDE will... This implies media control, ie. pointing authors of false reports to the one and only official statement instead of assuming sth. out of the meta-information (article/s or blogs about baloo ./. nepomuk etc.) (As KDE won't be paying a PR agency - i guess - that means by us) Once a decision has been settled, it's time to contact kde-pr...@kde.org on this topic. To shape an official note and get it out. http://community.kde.org/Baloo/NepomukPort Dolphin The port is in progress. Check the feature/baloo branch I assume this will say done before any transition happens? Amarok has a separate Nepomuk collection. Porting this is going to be next to impossible as it creates huge sparql queries. There should be at least a link to further information. atm. it reads like: We're gonna remove nepomuk and then amarok is broken and unfixable. Informations on whether things are actually in progress (prevent nobody seems to care? panic) would be nice. Cheers, Thomas
Re: Moving Baloo and Baloo-widgets into KDE SC
On Thursday 09 Jan 2014 21:52:52 Christoph Feck wrote: On Thursday 09 January 2014 13:42:12 Vishesh Handa wrote: Rough Update - The migrator has been written and tested for files. The tags, rating, comments and indexing configuration are properly migrated. Is this a one-time migration, or continuous migration? In other words, if a user tags a file using an unported application, will he be able to integrate that data into an already migrated data base? It's a one time migration. We have no idea what custom applications a user may use to tag files and later expects to find these tags using all other applications. Then that user will be part of the 1% that has a sub-par experience in comparison to the 99% who are going to be much much happier in a world where virtuoso is not hogging up their CPU. I prefer concentrating on the most common use cases. Considering that certain applications are still going to continue using Nepomuk for sometime. The plan is to move most of kde-runtime/nepomuk into its own repository which distributions can then choose to ship. The tags and timeline kioslave will be renamed to nepomuk-tags and nepomuk- timeline respectively. This is being done to avoid breaking the user experience, as 99% of the users will be migrating to Baloo and will expect their tag/timline related bookmarks to work as they did before. With this I feel that distributions that think Nepomuk is still a priority can ship the nepomuk-runtime repository which will allow users to enable Nepomuk and use it. Unless, someone still has objections I'll request a new repository for nepomuk-runtime, and ask the system admins to move baloo into kdesc. I hope that we will be able to completely remove the Nepomuk API for the frameworks releases, and only use Baloo, because I trust you that Baloo offers better performance than Nepomuk. I haven't decided what we want to do with Nepomuk Frameworks. I don't see the point of porting it. But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. We'll have the same problem with KF5. Not all applications will immediately port to Qt5 and KF5, and some might just continue to use Nepomuk and not move to Baloo. Christoph Feck (kdepepo) KDE Quality Team -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Fri, Jan 10, 2014 at 3:56 AM, Àlex Fiestas afies...@kde.org wrote: On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. I have to disagree here. We can't keep playing this conservative when we have things that are in the Nepomuk situation. If it is the most hated piece of software we have is not by chance. s/is the/was the. Nepomuk is very usable since few releases now, at least I am going to cry (as a user) if you're gonna break my alt+f2 search. If the breakage is minimal (which I know it is, but I will let vHanda reply to that) I vote to replace it even if we make a bit worse the experience using some weird application that nobody has heard of. Ps: Some distros even disable Nepomuk by default... Really with this we are going to annoying almost nobody. But not the distros which have the biggest userbase for KDE? (I'm thinking Kubuntu, OpenSUSE, Fedora-KDE) If we are *absolutely sure* we won't break stuff for the user, go ahead. But, lets not do a KDE 4.0 again, with Desktop Search. -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com
Re: Moving Baloo and Baloo-widgets into KDE SC
Am Donnerstag, 09. Januar 2014, 23.26:01 schrieb Àlex Fiestas: Morning Alex On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. I have to disagree here. And I'm probably disagree with you but let me explain below. We can't keep playing this conservative when we have things that are in the Nepomuk situation. If it is the most hated piece of software we have is not by chance. If the breakage is minimal (which I know it is, but I will let vHanda reply to that) I vote to replace it even if we make a bit worse the experience using some weird application that nobody has heard of. The release schedule for 4.13 is really short (4 month). With the feature freeze in approx. 1.5 months, see [1]. As 4.13 will be one of our last release in the 4 era I think we should be quite sure that we don't break anything or even more to be 110% sure to have fallbacks, migration, APIs for Nepomuk apps to access Baloo data etc. And even though I know that Vishesh is doing a great and a hell of a job I'm not too sure if one single person can manage all of this (not just the implementation but I think it needs a lot of testing as well). IIRC it's still not clear for all the current Nepomuk apps if they work after 4.13. Let's try to list them again. - Amarok (got Nepomuk support with 2.7, will it work after 4.13? - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer - Plasma Active/Plasma mobile with Share-Like-Connect And another question. Will people who used Nepomuk extensively lose data? I know that Nepomuk was one of the most hated software, but there were and are people who like(d) and love(d) it. So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. Ps: Some distros even disable Nepomuk by default... Really with this we are going to annoying almost nobody. Best regards Mario [1] http://techbase.kde.org/Schedules/KDE4/4.13_Release_Schedule
Re: Moving Baloo and Baloo-widgets into KDE SC
Hey, On Friday, January 10, 2014 11:02:22 Mario Fux KDE ML wrote: Am Donnerstag, 09. Januar 2014, 23.26:01 schrieb Àlex Fiestas: If the breakage is minimal (which I know it is, but I will let vHanda reply to that) I vote to replace it even if we make a bit worse the experience using some weird application that nobody has heard of. The release schedule for 4.13 is really short (4 month). With the feature freeze in approx. 1.5 months, see [1]. As 4.13 will be one of our last release in the 4 era I think we should be quite sure that we don't break anything or even more to be 110% sure to have fallbacks, migration, APIs for Nepomuk apps to access Baloo data etc. And even though I know that Vishesh is doing a great and a hell of a job I'm not too sure if one single person can manage all of this (not just the implementation but I think it needs a lot of testing as well). IIRC it's still not clear for all the current Nepomuk apps if they work after 4.13. Let's try to list them again. - Amarok (got Nepomuk support with 2.7, will it work after 4.13? If it's ported... - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? Maybe this feature is worth delaying then? - Dolphin - Gwenview - Conquiere - KPhotoalbum - Kamoso (seems so be ready in time) - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless) - Nepomuk-webminer and Nepomuktvnamer Let me point out the obvious here: We can discuss possible quality problems for a few more weeks, *OR* we use the time to actually test the code on a wider range of systems. This way we wouldn't have to guess so much about possible impact to other apps, and we can judge much better how ready Baloo is. Don't see Baloo as a third party service that someone else has to fix and debug, rather get on the train, test it, report your experience and make it possible to get it solidly working. - Plasma Active/Plasma mobile with Share-Like-Connect There's no Plasma Active release planned based on 4.x APIs, so this one can just be ignored until there's a clear and concrete roadmap. Likely, the next Plasma Active release will be folded into the Plasma workspaces anyway. Besides that, Plasma Active will be benefitting a lot from Baloo, since it's typically run on smaller devices. The pain here is limited since there are not too many users currently, and the parts of the system interfacing with Nepomuk (and Baloo in the future) are rather well defined. And another question. Will people who used Nepomuk extensively lose data? I know that Nepomuk was one of the most hated software, but there were and are people who like(d) and love(d) it. I think this question has been answered a few times already, even in this thread. So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. I'm not strictly against this. Actually, we have some lenience with the long term support workspace out, so we can recommend people to use that, if they're slightly more adventurous, run 4.13, if they are completely mad, help us getting Plasma 2 in shape. That's quite a nice array of options. Communicated in the right way to our downstreams, this helps us to avoid problems. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 10 Jan 2014 12:07:04 Shantanu Tushar Jha wrote: On Fri, Jan 10, 2014 at 3:56 AM, Àlex Fiestas afies...@kde.org wrote: On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. I have to disagree here. We can't keep playing this conservative when we have things that are in the Nepomuk situation. If it is the most hated piece of software we have is not by chance. s/is the/was the. Nepomuk is very usable since few releases now, at least I am going to cry (as a user) if you're gonna break my alt+f2 search. It won't break. It will work better than before. Baloo will provide a krunner plugin. -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 10 Jan 2014 11:02:22 Mario Fux KDE ML wrote: IIRC it's still not clear for all the current Nepomuk apps if they work after 4.13. Let's try to list them again. - Amarok (got Nepomuk support with 2.7, will it work after 4.13? No. It will not. There is no way this can be ported. It will need to be dropped and rewritten. However, given that Amarok still works perfectly without it, It's not going to break anything. - Digikam (gets new Nepomuk with 4.0.0 due in May or so. Will it work)? No. I should probably talk to the Digikam guys. - Dolphin Ported. See feature/baloo branch in kde-baseapps. - Gwenview Will be ported. - Conquiere Not going to be ported. Will require massive changes. The maintainer Jorg was contacted before the Baloo announcement, and he's happy to move away from Nepomuk to something else. - KPhotoalbum Can't say. - Kamoso (seems so be ready in time) I think Alex and Aleix can make sure this is ported. - Kdenlive (out of the most popular KDE apps, with some man power problems atm, ok, but nonetheless Can't say. They are probably just using tags. - Nepomuk-webminer and Nepomuktvnamer WebMiner and Conquiere have been both done by the same awesome guy - Jorg. His architecture will allow him to easily move away from Nepomuk. Though we still have to talk on how we're going to integrate it will Baloo (and if it is required) - Plasma Active/Plasma mobile with Share-Like-Connect They can continue to ship Nepomuk, and make sure it is enabled. And another question. Will people who used Nepomuk extensively lose data? I know that Nepomuk was one of the most hated software, but there were and are people who like(d) and love(d) it. No. They will not loose data. So in conclusion I think that a change of Nepomuk to Baloo in 4.x without a 100% (very very well tested!) migration plan and testing is a no-go (from my side, just me). I've the strong feeling that such big changes are for something like kf5 and a port of the apps to kf5. Then lets merge Baloo ASAP and get started with testing. Currently, it's just me and a hand full of others. If required we can sit and write testing guides, coordinate with the quality team, run blog posts asking for testers, etc. But that won't happen untill Baloo moves to SC because in order to test Baloo you need to test applications that use Baloo. -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
Rough Update - The migrator has been written and tested for files. The tags, rating, comments and indexing configuration are properly migrated. Considering that certain applications are still going to continue using Nepomuk for sometime. The plan is to move most of kde-runtime/nepomuk into its own repository which distributions can then choose to ship. The tags and timeline kioslave will be renamed to nepomuk-tags and nepomuk- timeline respectively. This is being done to avoid breaking the user experience, as 99% of the users will be migrating to Baloo and will expect their tag/timline related bookmarks to work as they did before. With this I feel that distributions that think Nepomuk is still a priority can ship the nepomuk-runtime repository which will allow users to enable Nepomuk and use it. Unless, someone still has objections I'll request a new repository for nepomuk-runtime, and ask the system admins to move baloo into kdesc. -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Wednesday 25 Dec 2013 23:49:12 Albert Astals Cid wrote: Please use a KCatalogLoader (and while at it fix it for nepomuk-widgets too Fixed -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Thursday 09 January 2014 13:42:12 Vishesh Handa wrote: Rough Update - The migrator has been written and tested for files. The tags, rating, comments and indexing configuration are properly migrated. Is this a one-time migration, or continuous migration? In other words, if a user tags a file using an unported application, will he be able to integrate that data into an already migrated data base? We have no idea what custom applications a user may use to tag files and later expects to find these tags using all other applications. Considering that certain applications are still going to continue using Nepomuk for sometime. The plan is to move most of kde-runtime/nepomuk into its own repository which distributions can then choose to ship. The tags and timeline kioslave will be renamed to nepomuk-tags and nepomuk- timeline respectively. This is being done to avoid breaking the user experience, as 99% of the users will be migrating to Baloo and will expect their tag/timline related bookmarks to work as they did before. With this I feel that distributions that think Nepomuk is still a priority can ship the nepomuk-runtime repository which will allow users to enable Nepomuk and use it. Unless, someone still has objections I'll request a new repository for nepomuk-runtime, and ask the system admins to move baloo into kdesc. I hope that we will be able to completely remove the Nepomuk API for the frameworks releases, and only use Baloo, because I trust you that Baloo offers better performance than Nepomuk. But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. Christoph Feck (kdepepo) KDE Quality Team
Re: Moving Baloo and Baloo-widgets into KDE SC
On Thursday 09 January 2014 21:52:52 Christoph Feck wrote: But if the above scenario does not work, we should probably not introduce Baloo for KDE SC 4.x. I have to disagree here. We can't keep playing this conservative when we have things that are in the Nepomuk situation. If it is the most hated piece of software we have is not by chance. If the breakage is minimal (which I know it is, but I will let vHanda reply to that) I vote to replace it even if we make a bit worse the experience using some weird application that nobody has heard of. Ps: Some distros even disable Nepomuk by default... Really with this we are going to annoying almost nobody.
Re: Moving Baloo and Baloo-widgets into KDE SC
Though not listed, plasma-mediacenter will move to baloo as soon as it gets a stable release. This is also a great excuse for us to spend time in fixing the tight coupling between our media collection logic and Nepomuk. On Fri, Dec 27, 2013 at 6:13 PM, Albert Astals Cid aa...@kde.org wrote: El Divendres, 27 de desembre de 2013, a les 13:24:14, Vishesh Handa va escriure: On Wednesday 25 Dec 2013 23:43:20 Albert Astals Cid wrote: The pim agent Messages.sh catalog name is wrong as discussed on IRC. Fixed balooshow and baloosearch are missing Messages.sh Fixed 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. Kill both of them. Neither of them will be able to search through information in Nepomuk. However, I do plan to write a simple application to migrate nepomuk tags, ratings and config settings into Baloo. The only remaining Nepomuk bit in kde-runtime will be the kcm, which should be removed as well. 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. That's the plan. The user continues to tag files how they used to previously. 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? The most notable use cases of Nepomuk are - 1. Dolphin - Nearly ported, needs more testing. 2. KMail - 80% done. Tags will be stored directly in Akonadi. Same for comments. So the only thing that had to be ported was searching. 3. GwenView - It'll be a simple port kde-workspace just has a runner and a dataengine. Both of those can be provided by Baloo if required. Activities - Will need to be ported. From my perspective it is a simple port that can be done during the Plasma sprint. What about the users of: digikam kphotoalbum amarok kamoso kdenlive rekonq tellico nepomuk-webminer plasma-mobile share-like-connect ? Cheers, Albert -- Shantanu Tushar(UTC +0530) http://www.shantanutushar.com
Re: Moving Baloo and Baloo-widgets into KDE SC
2013/12/27 Albert Astals Cid aa...@kde.org What about the users of: rekonq I'll be happy to move to Baloo in the upcoming KF5 series. Rekonq just uses Nepomuk to tag/rate bookmarks. I'll just need some explanations about moving the actual info. Cheers, -- Andrea Diamantini WEB: http://www.adjam.org rekonq project WEB: http://rekonq.kde.org IRC: rekonq@freenode
Re: Moving Baloo and Baloo-widgets into KDE SC
On Wednesday 25 Dec 2013 23:43:20 Albert Astals Cid wrote: The pim agent Messages.sh catalog name is wrong as discussed on IRC. Fixed balooshow and baloosearch are missing Messages.sh Fixed 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. Kill both of them. Neither of them will be able to search through information in Nepomuk. However, I do plan to write a simple application to migrate nepomuk tags, ratings and config settings into Baloo. The only remaining Nepomuk bit in kde-runtime will be the kcm, which should be removed as well. 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. That's the plan. The user continues to tag files how they used to previously. 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? The most notable use cases of Nepomuk are - 1. Dolphin - Nearly ported, needs more testing. 2. KMail - 80% done. Tags will be stored directly in Akonadi. Same for comments. So the only thing that had to be ported was searching. 3. GwenView - It'll be a simple port kde-workspace just has a runner and a dataengine. Both of those can be provided by Baloo if required. Activities - Will need to be ported. From my perspective it is a simple port that can be done during the Plasma sprint. -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
El Divendres, 27 de desembre de 2013, a les 13:24:14, Vishesh Handa va escriure: On Wednesday 25 Dec 2013 23:43:20 Albert Astals Cid wrote: The pim agent Messages.sh catalog name is wrong as discussed on IRC. Fixed balooshow and baloosearch are missing Messages.sh Fixed 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. Kill both of them. Neither of them will be able to search through information in Nepomuk. However, I do plan to write a simple application to migrate nepomuk tags, ratings and config settings into Baloo. The only remaining Nepomuk bit in kde-runtime will be the kcm, which should be removed as well. 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. That's the plan. The user continues to tag files how they used to previously. 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? The most notable use cases of Nepomuk are - 1. Dolphin - Nearly ported, needs more testing. 2. KMail - 80% done. Tags will be stored directly in Akonadi. Same for comments. So the only thing that had to be ported was searching. 3. GwenView - It'll be a simple port kde-workspace just has a runner and a dataengine. Both of those can be provided by Baloo if required. Activities - Will need to be ported. From my perspective it is a simple port that can be done during the Plasma sprint. What about the users of: digikam kphotoalbum amarok kamoso kdenlive rekonq tellico nepomuk-webminer plasma-mobile share-like-connect ? Cheers, Albert
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 27 December 2013 13:43:50 Albert Astals Cid wrote: El Divendres, 27 de desembre de 2013, a les 13:24:14, Vishesh Handa va escriure: On Wednesday 25 Dec 2013 23:43:20 Albert Astals Cid wrote: The pim agent Messages.sh catalog name is wrong as discussed on IRC. Fixed balooshow and baloosearch are missing Messages.sh Fixed 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. Kill both of them. Neither of them will be able to search through information in Nepomuk. However, I do plan to write a simple application to migrate nepomuk tags, ratings and config settings into Baloo. The only remaining Nepomuk bit in kde-runtime will be the kcm, which should be removed as well. 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. That's the plan. The user continues to tag files how they used to previously. 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? The most notable use cases of Nepomuk are - 1. Dolphin - Nearly ported, needs more testing. 2. KMail - 80% done. Tags will be stored directly in Akonadi. Same for comments. So the only thing that had to be ported was searching. 3. GwenView - It'll be a simple port kde-workspace just has a runner and a dataengine. Both of those can be provided by Baloo if required. Activities - Will need to be ported. From my perspective it is a simple port that can be done during the Plasma sprint. What about the users of: kamoso We will kamoso to Baloo the moment it is in extragear.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 24 December 2013 23:32:27 Thomas Lübking wrote: On Dienstag, 24. Dezember 2013 22:03:28 CEST, Àlex Fiestas wrote: On Tuesday 24 December 2013 21:25:37 Ivan Čukić wrote: I would like baloo to be available in 4.x, with no API stability guarantees, ... As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. Since actual ABI is not affected (in terms of things start to crash), you /can/ do whatever you want, but it still has consequences. 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. We (I have worked on this) have done our homework, we know all applications that use Nepomuk (extragear, playground and kde-look) and how they use it. In most cases it is not even working, in the case where it is they usually only use tag/notes/ratings. The most notorious exceptions are to this rule are nepgoogle and webminer. Maintainers of both projects are already working on porting them to Baloo. So either nepomuk and baloo can run (and sync) side by side or there eventually needs to be some sort of API wrapper and a very LOUD heads-up! to distros to relink everything that's not been ported, so to have baloo *completely* replace nepomuk - or baloo can still be added to allow devs migrate to it, but in general we stick with nepomuk until P-W/2. This is not about the quality or sheer sanity advance of Baloo, but the bare necessities (yes ;-) of release management. Let me say again, Nepomuk is not going anyway for 4.XX, people will still be able to use it (having it indexing files and what not) if they so require. Finally, I do thing we should make Nepomuk talk to Baloo so they can keep tags/notes/ratings in Sync, which at the end is the only thing that really matters. Cheers.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Wednesday 25 December 2013 01:13:33 Ivan Čukić wrote: On Tuesday, 24. December 2013. 22.03.28 Àlex Fiestas wrote: As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. The truthfulness of Vishesh's claim does not enter into it. If we believe it (and I do), it works better *only* for the things that are ported to it. What of applications that are not ([1] as an example of a 3rd party app)? Users that wants to continue using Nepoogle can continue to do so, worse case scenario will have two things indexing files, one of them will be really fast though.
Re: Moving Baloo and Baloo-widgets into KDE SC
The most notorious exceptions are to this rule are nepgoogle and webminer. Maintainers of both projects are already working on porting them to Baloo. This I like. Baloo seems to be working very nice (I've been running it for some time now), so if all clients are being ported, then I have no problems with the transition. It just *needs* to be smooth and stable. It would be awful if the first impression of baloo was the same as with the first releases of plasma and nepomuk. Cheerio, Ivan -- Progress isn't made by early risers. It's made by lazy men trying to find easier ways to do something. -- Robert Heinlein
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 27 December 2013 18:31:19 Ivan Čukić wrote: It just *needs* to be smooth and stable. It would be awful if the first impression of baloo was the same as with the first releases of plasma and nepomuk. Maybe the Nepomuk/Baloo developers could think about a fallback plan in case problems arise during the beta and release candidate testing? Thinking back about the major technology transitions in the 4.x... well we didn't do a good job with those. We should learn from our mistakes ;-) Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 27 December 2013 18:45:09 Martin Graesslin wrote: On Friday 27 December 2013 18:31:19 Ivan Čukić wrote: It just *needs* to be smooth and stable. It would be awful if the first impression of baloo was the same as with the first releases of plasma and nepomuk. Maybe the Nepomuk/Baloo developers could think about a fallback plan in case problems arise during the beta and release candidate testing? Thinking back about the major technology transitions in the 4.x... well we didn't do a good job with those. We should learn from our mistakes ;-) Yeah we should be prepared.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday 27 December 2013 18:31:19 Ivan Čukić wrote: The most notorious exceptions are to this rule are nepgoogle and webminer. Maintainers of both projects are already working on porting them to Baloo. This I like. Baloo seems to be working very nice (I've been running it for some time now), so if all clients are being ported, then I have no problems with the transition. It just *needs* to be smooth and stable. It would be awful if the first impression of baloo was the same as with the first releases of plasma and nepomuk. Cheerio, Ivan Indeed, if we are proposing this for 4.13 it is because we are deeply committed on making sure Baloo actually *fixes* the problem. The switch will only be done once Baloo covers all Nepomuk functionality offered by the SC. To ensure that the quality is actually better than Nepomuk we want to make this dog-foodable as soon as possible for all users of KDE SC master, since right now the only interface to use Baloo is Milou[1] (which works wonderfully btw). Special focus is being put on resource consumption, and here there is no doubt that Baloo uses less Memory (ram and disk) and less CPU than Nepomuk. At the moment of writing this: baloo_file: RAM: 55M Disk: 221M Query: 027ms Emails: 317560 in 6.6min (index time 2.1) Files: 27K in 5min (phase 1 and 2) Nepomuk: RAM: 700M Disk: 191M Query: 332ms Index time: 5h for 13K files (phase 1 and 2) Emails: 7000 in 1h, meaning it will take 41h for 30K. Indexing time gets worse with time, it was around 500ms per email when I stopped it, from my experience it gets easy into 700ms. The query was Ivan. Given this results, worse case scenario to get all functionality we actually have with Nepomuk (which will mean having baloo and nepomuk running at the same time) will mean that much overhead, which imho is acceptable. Cheers !
Re: Moving Baloo and Baloo-widgets into KDE SC
On Friday, 27 December 2013 13:43:50 CEST, Albert Astals Cid wrote: kphotoalbum Unless I'm terribly mistaken, KPhotoAlbum uses just the stars widget. The actual rating is saved in its own DB. We do care about the backwards compatibility, though, which means that a released tarball needs to work with previous KDE versions (up to some undefined release) as well. A flag-day change from #include nepomuk to #include baloo would not work well, but a simple #ifdef which can easily be triggered by finding a cmake package via pkgconfig or so is fine. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
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
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.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 24 December 2013 11:28:11 Vishesh Handa wrote: 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 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. How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. Christoph Feck (kdepepo) KDE Quality Team
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 24 Dec 2013 13:06:55 Christoph Feck wrote: How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. I'm confused on how not sharing metadata = ABI break? Could you please elaborate? -- Vishesh Handa
Re: Moving Baloo and Baloo-widgets into KDE SC
On Dienstag, 24. Dezember 2013 19:29:11 CEST, Vishesh Handa wrote: On Tuesday 24 Dec 2013 13:06:55 Christoph Feck wrote: How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. I'm confused on how not sharing metadata = ABI break? Could you please elaborate? If baloo can neither coexist with and talk to nepomuk, nor is 100% ABI compatible on clientlib (wrapper?) side, it cannot just replace nepomuk. Cheers, Thomas
Re: Moving Baloo and Baloo-widgets into KDE SC
On 24 Dec 2013 18:57, Thomas Lübking thomas.luebk...@gmail.com wrote: On Dienstag, 24. Dezember 2013 19:29:11 CEST, Vishesh Handa wrote: On Tuesday 24 Dec 2013 13:06:55 Christoph Feck wrote: How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. I'm confused on how not sharing metadata = ABI break? Could you please elaborate? If baloo can neither coexist with and talk to nepomuk, nor is 100% ABI compatible on clientlib (wrapper?) side, it cannot just replace nepomuk. As I understand it there are no plans to remove the nepomuk-core or nepomuk-widget libraries. If you switch to Baloo, anything compiled against nepomuk will still run but will act as if nepomuk is disabled. This is something clients previously had to cope with anyway. David Cheers, Thomas
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 24 December 2013 21:25:37 Ivan Čukić wrote: As I understand it there are no plans to remove the nepomuk-core or nepomuk-widget libraries. If you switch to Baloo, anything compiled against nepomuk will still run but will act as if nepomuk is disabled. This is something clients previously had to cope with anyway. Meaning that everything* that uses nepomuk now (fortunately, not much) will stop working properly. Either that, or we will have to keep both systems running in-parallel. * except the parts Vishesh ports over :) I would like baloo to be available in 4.x, with no API stability guarantees, so that it can mature for 5.x series. I am not sure about pushing it as a nepomuk replacement just jet. As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. Vishesh, how possible would it be to have dolphin (and others) with support for both nepomuk and baloo? I don't know details but ofc it is possible, but I doubt we have the manpower to do it (it will take longer and it will require more maintainership).
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday 24 December 2013 19:57:17 Thomas Lübking wrote: On Dienstag, 24. Dezember 2013 19:29:11 CEST, Vishesh Handa wrote: On Tuesday 24 Dec 2013 13:06:55 Christoph Feck wrote: How does Baloo cooperate with Nepomuk? Note that we have ABI guarantees, so if the metadata is not shared between running instances of two services, but applications would have to be ported to the new ABI, then you cannot introduce Baloo in KDE 4.x, but only for KF5. I'm confused on how not sharing metadata = ABI break? Could you please elaborate? If baloo can neither coexist with and talk to nepomuk, nor is 100% ABI compatible on clientlib (wrapper?) side, it cannot just replace nepomuk. Workspace doesn't keep any kind of compatibility so we can do what we please there. In kdelibs, Nepomuk will continue working as it does right now, so applications that support it will continue doing so.
Re: Moving Baloo and Baloo-widgets into KDE SC
On Dienstag, 24. Dezember 2013 22:03:28 CEST, Àlex Fiestas wrote: On Tuesday 24 December 2013 21:25:37 Ivan Čukić wrote: I would like baloo to be available in 4.x, with no API stability guarantees, ... As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. Since actual ABI is not affected (in terms of things start to crash), you /can/ do whatever you want, but it still has consequences. 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. So either nepomuk and baloo can run (and sync) side by side or there eventually needs to be some sort of API wrapper and a very LOUD heads-up! to distros to relink everything that's not been ported, so to have baloo *completely* replace nepomuk - or baloo can still be added to allow devs migrate to it, but in general we stick with nepomuk until P-W/2. 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 =) Cheers, Thomas (To leave no question: the sooner virtuoso leaves my desktop system, the better)
Re: Moving Baloo and Baloo-widgets into KDE SC
On Tuesday, 24. December 2013. 22.03.28 Àlex Fiestas wrote: As I see it, the nepomuk maintainer says it works better than Nepomuk for all cases covered by SC. I don't see any reason not to move forward then. The truthfulness of Vishesh's claim does not enter into it. If we believe it (and I do), it works better *only* for the things that are ported to it. What of applications that are not ([1] as an example of a 3rd party app)? hypothetical: Were we able to make khtml render nothing while preserving api and abi because we decided that webkit was better? Cheerio, Ivan [1] http://kde-apps.org/content/show.php?content=145505 -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
