Re: The Nepomuk Situation
On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management-se rvice/ -- Vishesh Handa
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 5:01 AM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 2 de maig de 2012, a les 12:14:00, Ivan Cukic va escriure: The first solution - * Remove nepomuk from kdelibs and kde-runtime +1 This is what has been done with kactivities. Instead of having it in kdelibs and runtime, it is now all in one repository. The only difference here is that nepomuk is not in libs/experimental like libkactivities was. This is a huge difference, we *promise* to keep SC and BC of our libs, doing the first solution would totally go against our promises. Right. We could maintain BC and SC by not touching the kdelibs nepomuk, and just making nepomuk-core a dependency of kdelibs. But that would result in both nepomuk-core and kdelibs installing the same headers. Cheers, Albert I think that this would help KF5 efforts since applications would start porting early to the new libraries. Again, the only downside being the fact that libnepomuk will not be able to stay binary (or api) back-compatible due to uses of KUrl and similars (it it hasn't already been removed in the nepomuk-core) Cheerio, Ivan * Make nepomuk-core a compile time dependency for kdelibs * Including the missing gui code into nepomuk-core The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/ -- Vishesh Handa
Re: The Nepomuk Situation
On 2012-05-07, Vishesh Handa m...@vhanda.in wrote: Right. We could maintain BC and SC by not touching the kdelibs nepomuk, and just making nepomuk-core a dependency of kdelibs. But that would result in both nepomuk-core and kdelibs installing the same headers. what happens if both libraries are loaded into the same process? /Sune
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela nos...@vuorela.dk wrote: On 2012-05-07, Vishesh Handa m...@vhanda.in wrote: Right. We could maintain BC and SC by not touching the kdelibs nepomuk, and just making nepomuk-core a dependency of kdelibs. But that would result in both nepomuk-core and kdelibs installing the same headers. what happens if both libraries are loaded into the same process? I'm not sure. I'm assuming that it would result in some sort of linker errors. How is this relevant? kdelibs installs the folowing nepomuk libraries - libnepomuk, libnepomukquery and libnepomukutils nepomuk-core combines all of them along with the new apis under the name - libnepomukcore /Sune -- Vishesh Handa
Re: Pairs going to KDE Edu
On Mon, May 7, 2012 at 2:08 AM, Albert Astals Cid aa...@kde.org wrote: El Dimarts, 1 de maig de 2012, a les 22:16:44, Aleix Pol va escriure: On Tue, May 1, 2012 at 9:29 AM, Aleix Pol aleix...@kde.org wrote: On Mon, Apr 30, 2012 at 10:07 AM, Yuri Chornoivan yurc...@ukr.net wrote: написане Mon, 30 Apr 2012 02:36:38 +0300, Aleix Pol aleix...@kde.org: On Mon, Apr 16, 2012 at 3:35 AM, Aleix Pol aleix...@kde.org wrote: Hi, Last friday Pairs [1] was moved from playground/edu to kdereview because we want it to be moved to kdeedu. We have been working on it for a while already and we would like it to move to kde edu and to be included in the next KDE release. If someone is interested, please take a look into it and tell us what you think. Thanks! Aleix PS: It has a notable artwork lacking that's being worked on, slowly. Although if anybody is interested in joining, we are welcoming people :). [1] https://projects.kde.org/projects/kdereview/pairs Since no big complaints were raised and the 2 week period passed already, I'll ask the sysadmin team to move Pairs to KDE Edu. :) Thanks to all those who cared. ^^ Aleix Hi, Just for the record, I think the issues found by Albert Astals Cid [1] were not fixed. Pairs is still untranslatable for KDE translation teams. Thanks for fixing this. Best regards, Yuri [1] http://lists.kde.org/?l=kde-edum=133468189317856w=2 ___ kde-edu mailing list kde-...@mail.kde.org https://mail.kde.org/mailman/listinfo/kde-edu I think these are fixed now. Sorry for missing those! . Aleix Pairs has been moved to KDE Edu. If anybody has any problem with it, don't hesitate to contact us! I do, your repo is still marked as inactive as I wrote in my original e-mail. Please fix that. You know where to find me if you have problems fixing that. Cheers, Albert Aleix Already fixed, hopefully for real :P Sorry about that! Aleix
Re: The Nepomuk Situation
On Monday 07 May 2012 13:06:15 Vishesh Handa wrote: On Mon, May 7, 2012 at 12:44 PM, Sune Vuorela nos...@vuorela.dk wrote: On 2012-05-07, Vishesh Handa m...@vhanda.in wrote: Right. We could maintain BC and SC by not touching the kdelibs nepomuk, and just making nepomuk-core a dependency of kdelibs. But that would result in both nepomuk-core and kdelibs installing the same headers. what happens if both libraries are loaded into the same process? I'm not sure. I'm assuming that it would result in some sort of linker errors. Not if libnepomukcore is brought in by the application, and libnepomuk is brought in by a dlopened plugin. In such a case, you get no clear error, you get random crashes. The solution is usually to namespace the symbols (classes, standalone functions etc.) so that they don't conflict. Of course that makes the porting effort a bit higher, but it's the only way to have both things side by side during the transition period. See knewstuff2 (namespace KNS) vs knewstuff3 (namespace KNS3) for instance ;) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5
Re: Review Request: Avoid using QDialog::exec in kpasswdserver to address long standing issue
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104817/#review13526 --- Smart pointers without a purpose, just make reading the code harder. Two more to fix, and then ship it ;) kpasswdserver/kpasswdserver.cpp http://git.reviewboard.kde.org/r/104817/#comment10694 This QPointer is useless too, given that you don't use exec(), but open(), which returns immediately - no nested event loop, no risk of deletion. kpasswdserver/kpasswdserver.cpp http://git.reviewboard.kde.org/r/104817/#comment10695 Same here. - David Faure On May 4, 2012, 11:01 p.m., Dawit Alemayehu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/104817/ --- (Updated May 4, 2012, 11:01 p.m.) Review request for KDE Runtime and David Faure. Description --- The attached patch does the following: - Use QDialog::open instead of QDialog::exec to prevent one password dialog from blocking other password dialogs. This fixes the changes committed with https://git.reviewboard.kde.org/r/103245/ which allowed dialog boxes from different applications to be shown so long as they are not for the same site. - Update the key under which the password is cached if the request url contains a username, but the user change it in the password dialog. IOW, do now allow a password to be stored under different username than the one used to access the site. - Added the unit test listed in the TODOs along with several more that exercise all of the above changes. Diffs - kpasswdserver/DESIGN 6a128f9 kpasswdserver/kpasswdserver.h 66f1f57 kpasswdserver/kpasswdserver.cpp b2abbd4 kpasswdserver/tests/kpasswdservertest.cpp 38a579b Diff: http://git.reviewboard.kde.org/r/104817/diff/ Testing --- Added several additional unit tests to exercise all the changes. See patch. Thanks, Dawit Alemayehu
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org wrote: On 05/07/2012 12:09 PM, Vishesh Handa wrote: So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( Well, I suppose we could make this work with some sed magic. :P I would vote for option 3 which could then be reverted (or not) for kde5. I would prefer option 2. The mysterious crashes would only happen if an application's plugin links to the incorrect libraries. Is that a possibility for us? We have about 8-10 known nepomukservices, which are basically plugins but *they exist in their own process*, so each has their own libraries. -- Vishesh Handa
Re: The Nepomuk Situation
On 05/07/2012 02:35 PM, Vishesh Handa wrote: On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org mailto:tr...@kde.org wrote: On 05/07/2012 12:09 PM, Vishesh Handa wrote: So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( Well, I suppose we could make this work with some sed magic. :P I would vote for option 3 which could then be reverted (or not) for kde5. I would prefer option 2. The mysterious crashes would only happen if an application's plugin links to the incorrect libraries. Is that a possibility for us? I already experienced that. Took me a while to find the reason. We have about 8-10 known nepomukservices, which are basically plugins but *they exist in their own process*, so each has their own libraries. -- Vishesh Handa
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg tr...@kde.org wrote: On 05/07/2012 02:35 PM, Vishesh Handa wrote: On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org mailto:tr...@kde.org wrote: On 05/07/2012 12:09 PM, Vishesh Handa wrote: So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( Well, I suppose we could make this work with some sed magic. :P I would vote for option 3 which could then be reverted (or not) for kde5. I would prefer option 2. The mysterious crashes would only happen if an application's plugin links to the incorrect libraries. Is that a possibility for us? I already experienced that. Took me a while to find the reason. Alright. I would like the Nepomuk2 namespace and include directories be removed for the frameworks, but I guess it is not a big deal if that doesn't happen. Okay, everyone. This is the point where you chime in and say - We're okay with this or you raise your objections. We would like to get this mess sorted in time for the 4.9 release. -- Vishesh Handa
Re: The Nepomuk Situation
On 05/07/2012 03:47 PM, ivan.cu...@gmail.com wrote: Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in the future, we could just change the macro value. That would be much more work since each cpp file has the namespaces in the method definitions. I don't know, thinking that Nepomuk2 namespace is looking rather ugly :) it is indeed. The dirtiest solution library-wise would be to have everything in NepomukCore::Nepomuk::Something so that the only change in the current code of nepomuk users would be a using namespace NepomukCore; Sorry for being a bit vague, I'm writing from my phone. Cheerio, IvanOn 7.5.12. 14.49 Vishesh Handa wrote: On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg tr...@kde.org wrote: On 05/07/2012 02:35 PM, Vishesh Handa wrote: On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org mailto:tr...@kde.org wrote: On 05/07/2012 12:09 PM, Vishesh Handa wrote: So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( Well, I suppose we could make this work with some sed magic. :P I would vote for option 3 which could then be reverted (or not) for kde5. I would prefer option 2. The mysterious crashes would only happen if an application's plugin links to the incorrect libraries. Is that a possibility for us? I already experienced that. Took me a while to find the reason. Alright. I would like the Nepomuk2 namespace and include directories be removed for the frameworks, but I guess it is not a big deal if that doesn't happen. Okay, everyone. This is the point where you chime in and say - We're okay with this or you raise your objections. We would like to get this mess sorted in time for the 4.9 release.
Re: The Nepomuk Situation
Maybe there could be something like qt has - BEGIN_NEPOMUK_NAMESPACE... So that if the same needs to be done in the future, we could just change the macro value. I don't know, thinking that Nepomuk2 namespace is looking rather ugly :) The dirtiest solution library-wise would be to have everything in NepomukCore::Nepomuk::Something so that the only change in the current code of nepomuk users would be a using namespace NepomukCore; Sorry for being a bit vague, I'm writing from my phone. Cheerio, IvanOn 7.5.12. 14.49 Vishesh Handa wrote: On Mon, May 7, 2012 at 6:13 PM, Sebastian Trüg tr...@kde.org wrote: On 05/07/2012 02:35 PM, Vishesh Handa wrote: On Mon, May 7, 2012 at 5:54 PM, Sebastian Trüg tr...@kde.org mailto:tr...@kde.org wrote: On 05/07/2012 12:09 PM, Vishesh Handa wrote: So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( Well, I suppose we could make this work with some sed magic. :P I would vote for option 3 which could then be reverted (or not) for kde5. I would prefer option 2. The mysterious crashes would only happen if an application's plugin links to the incorrect libraries. Is that a possibility for us? I already experienced that. Took me a while to find the reason. Alright. I would like the Nepomuk2 namespace and include directories be removed for the frameworks, but I guess it is not a big deal if that doesn't happen. Okay, everyone. This is the point where you chime in and say - We're okay with this or you raise your objections. We would like to get this mess sorted in time for the 4.9 release. -- Vishesh Handa
Re: Review Request: KMessageWidget: Adapt height to text changes
On May 2, 2011, 5:49 p.m., Aurélien Gâteau wrote: Thanks for the patch Mattias! This is indeed an annoying bug but your fix does not work when the widget is resized. heightForWidth() needs to be implemented I think. Matthias Fuchs wrote: The problem is that resizing takes no effect yet either. Here without the patch enabling word wrap instantly increases the height, even if there is enough horizontal space. So the fix would not make matters worse. I am not sure how to fix the height problem in general though. To me it appears that QLabel is lacking here. (Answering almost one year later, new record :/) I worked a bit on KMessageWidget two weeks ago, the current version in KDE/4.8 should correctly adjusts its height when wrapping and react to resizing. Can you test it? - Aurélien --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101272/#review3071 --- On May 2, 2011, 12:35 p.m., Matthias Fuchs wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101272/ --- (Updated May 2, 2011, 12:35 p.m.) Review request for kdelibs and Aurélien Gâteau. Description --- When there is a long or wrapping text, the text is cut off. This patch fixes that. Diffs - kdeui/widgets/kmessagewidget.cpp 212ea0d Diff: http://git.reviewboard.kde.org/r/101272/diff/ Testing --- Screenshots --- http://git.reviewboard.kde.org/r/101272/s/154/ http://git.reviewboard.kde.org/r/101272/s/155/ Thanks, Matthias Fuchs
Package Dependcies List on Techbase
Howdy, I started putting the list of package dependences (arranged by module) onto Techbase. http://techbase.kde.org/Getting_Started/Build/Requirements The tables on the subpages there are generated by a perl program I wrote. That program reads the CMakeLists.txt files inside a module and generates wiki content I then copy+paste into Techbase. Please review for accuracy. For example: Why are attica and phonon REQUIRED for kde-runtime?? I'll be finishing up the list in the coming days.
Re: The Nepomuk Situation
El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? Albert Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? Yes they can still use the old apis, but it would be horribly horribly slow and would create a lot of useless data in the process. Also somethings like change monitoring and merging resources are flat out impossible. I'm not okay with applications having to stick with the old faulty APIs when we have put in so much effort to make these new ones. Also, can we substitute the word old apis with kdelibs/nepomuk apis and new apis with datamangement apis. This is getting a little confusing. Albert Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/ -- Vishesh Handa
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 10:12 PM, Sune Vuorela nos...@vuorela.dk wrote: On 2012-05-07, Vishesh Handa m...@vhanda.in wrote: I'm not okay with applications having to stick with the old faulty APIs I'm not okay with a api or abi break in kdelibs. Of course. But that is not what is happening. The current solution we propose is that we no not touch kdelibs/nepomuk. We release the nepomuk-core repository as a dependency of kde-runtime/kdelibs (you choose) which installs headers under nepomuk2, instead of the conventional nepomuk. And the namespace in nepomuk-core will be changed from nepomuk to nepomuk2. This way there are absolutely no clashes. Is that alright with you? /Sune -- Vishesh Handa
Re: The Nepomuk Situation
On Monday, 2012-05-07, Vishesh Handa wrote: On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? I think what Albert is asking is whether applications using the old APIs can continue to do so even if other applications are using the new APIs. Or whether the old APIs become unavailable of dysfunctional when the new ones are introduced. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 10:21 PM, Kevin Krammer kram...@kde.org wrote: On Monday, 2012-05-07, Vishesh Handa wrote: On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? I think what Albert is asking is whether applications using the old APIs can continue to do so even if other applications are using the new APIs. Or whether the old APIs become unavailable of dysfunctional when the new ones are introduced. oh Yes. Both APIs will continue to exist. They both solve different use cases, and are required. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring -- Vishesh Handa
Re: The Nepomuk Situation
El Dilluns, 7 de maig de 2012, a les 22:09:01, Vishesh Handa va escriure: On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure: On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va escriure: Hey everyone! snip The second solution is - * nepomuk-core installs the headers in nepomuk2 * the library already has a different name, so there are no clashes over there * kde-runtime/nepomuk is removed * nepomuk-core is added as a dependency of kde-runtime The problem with the second solution is that all applications using Nepomuk will also need to depend on nepomuk-core. So far the list includes - Dolphin, KDE-pim and Telepathy (kinda) Why is this needed? Can't they continue using the old APIs? Short answer: No Long Answer: The original Nepomuk APIs that are present in kdelibs are synchronous. They basically provide a glorified cache over the Nepomuk data which is stored in virtuoso. Applications which push large amounts of information into Nepomuk (Feeders) do not need to know anything about the data already present in Nepomuk, they just need to push large quantities of data as fast as they can. Using the synchronous kdelibs APIs makes this very hard. Additionally, the asynchronous API for pushing data provides has in-built duplicate detection and merging. That's something that was *very hard* to implement. It seems like an overkill for the clients to implement something like that on their own. kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV Naming Application. Secondly, the APIs in kdelibs did not provide any mechanism for monitoring changes in resources. We've now finally implemented a good method of monitoring changes that does not tax the entire system. Dolphin uses this new ResourceWatcher API to monitor for changes in tags and ratings. And finally, the new APIs provide a method for properly merging resources. A couple of miscellaneous applications are using this - Nepomuk Tag manager. Btw, when I say new APIs, I mean introduced in kde-runtime 4.7. So they are about a year old. So you mean yes, they can, they do now and can still do it, even if using the old APIs are suboptimal. Right? I'm sorry. What? Yes they can still use the old apis, but it would be horribly horribly slow and would create a lot of useless data in the process. Also somethings like change monitoring and merging resources are flat out impossible. I'm not okay with applications having to stick with the old faulty APIs when we have put in so much effort to make these new ones. Also, can we substitute the word old apis with kdelibs/nepomuk apis and new apis with datamangement apis. This is getting a little confusing. There's some problem of communication here. Let me try to explain myself better. As far as I understand: * Dolphin uses the old api at the moment and works fine * When the change you propose (adding new apis), you said the old api will still be there for people to use * The question is: If dolphin is not changed to use the new api and still uses the old api will it still work as it works now or will be worse? Hope i'm clearer now. Cheers, Albert Albert Cheers, Albert What do you guys think? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core [2] http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management- se rvice/
Re: The Nepomuk Situation
On Mon, May 7, 2012 at 10:57 PM, Albert Astals Cid aa...@kde.org wrote: There's some problem of communication here. Let me try to explain myself better. As far as I understand: * Dolphin uses the old api at the moment and works fine Yup. * When the change you propose (adding new apis), you said the old api will still be there for people to use Yup * The question is: If dolphin is not changed to use the new api and still uses the old api will it still work as it works now or will be worse? It will continue to work exactly the way it does right now. Hope i'm clearer now. Cheers, Albert -- Vishesh Handa
Re: The Nepomuk Situation
On Monday 07 May 2012, Vishesh Handa wrote: ... So, we're down to 3 options - *1.* nepomuk-core become a dependency of kdelibs. Kdelibs is not touched. *Problem:* Overlapping headers and possible mysterious crashes if both libraries are loaded. *2.* nepomuk-core installs headers under nepomuk2. It's released independently. *Problem:* Mysterious crashes if both libraries are loaded. *3.* nepomuk-core installs headers under nepomuk2 and the namespace is changed to nepomuk2. *Problem:* A lot more work :( In all cases, kde-runtime/nepomuk will be removed. Binary and Source compatibility are not affected. IMO this list looks like option 3 is actually the only viable option. Alex
Re: TechBase git policies, infrastructure documentation, please
Alexander Neundorf wrote: It would be just *great* if you could put this on techbase.kde.org :-) I'd suggest you just copy it into wherever you would look for it. Mostly it's not kde specific anyway. It's just about knowing how to use git. Thanks, Steve.
