Re: Product versions on bugs.kde.org
On Sun, Mar 13, 2016 at 7:57 PM, David Faure <fa...@kde.org> wrote: > On Saturday 12 March 2016 20:38:43 Vishesh Handa wrote: >> >> And from my point of view the user doesn't care if Baloo is part of >> something called "Frameworks". There is a bug, they want to report it. >> It's just added noise. > > Typically, users report bugs in the app where they see them, and then > the maintainer of the app reassigns to the "guilty" underlying framework. > > E.g. end users don't report kio bugs, they report dolphin bugs, which then > get reassigned to frameworks-kio. > > So I think frameworks-baloo makes sense (and is consistent). The "users" > of the framework are application developers, who know how to find it in > bugzilla. Except that Baloo isn't just a library. It provides a daemon, and a CLI search interface. I also know a few people running Baloo on servers. This whole "frameworks-baloo" vs "baloo" seems more pedantic than anything else. Specially considering the amount of overhead this is actively causing. I just have a crash report from 2 hours ago filed to Baloo (not Baloo-frameworks). Bug reports against previous versions of Baloo won't automatically go to this new "baloo-frameworks". And I have over 130+ new bug emails, which aren't relevant. I'm all for consistency, but not when it has a real cost. -- Vishesh Handa
Re: Product versions on bugs.kde.org
On Sat, Mar 12, 2016 at 4:02 AM, Alexander Potashev <aspotas...@gmail.com> wrote: > 7. Created product frameworks-baloo and added versions 5.13.0+ [4]. > Bugs for older, out-of-KF5 versions go into the "Baloo" product. > For the record, this just doubles the number of places I need to look. And from my point of view the user doesn't care if Baloo is part of something called "Frameworks". There is a bug, they want to report it. It's just added noise. > 8. Added product "BalooWidgets", it's part of KDE Applications. Moved > relevant bugs from the "Baloo" product. Sure .. I guess. I don't see the advantage apart from just being pedantic. > 9. Added product "Baloo KCM", it's part of Plasma > (plasma-desktop.git/kcms/baloo). Moved relevant bugs from the "Baloo" > product. > Then move it under Plasma? Or sure. > I guess now the products "kpeople" and "Baloo" can be obsoleted in Bugzilla. > > > If the above looks good, please add the product "Baloo KCM" into > releaseme.git/plasma/plasma-add-bugzilla-versions. In the future, I would appreciate it if such decisions were run by the maintainer. I now have more work since my existing filters and bookmarks are now invalid. And the documentation which tells where to file a bug. -- Vishesh Handa
Re: Review Request 119890: [Ark] Implement "Add to archive" option when dragging and dropping onto an archive file in dolphin
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119890/#review86362 --- Ship it! app/addToArchiveDndPlugin.cpp (line 38) <https://git.reviewboard.kde.org/r/119890/#comment59486> Empty new line. Plus this entire function is idented in a strange way. app/addToArchiveDndPlugin.cpp (line 44) <https://git.reviewboard.kde.org/r/119890/#comment59489> const KUrl& i app/addToArchiveDndPlugin.cpp (line 59) <https://git.reviewboard.kde.org/r/119890/#comment59487> Extra indent over here. app/addToArchiveDndPlugin.cpp (line 70) <https://git.reviewboard.kde.org/r/119890/#comment59488> The * is next to the type in the rest of the file. `KAction* action` instead of `KAction *action`. - Vishesh Handa On Aug. 21, 2014, 9:11 p.m., Arjun AK wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119890/ > --- > > (Updated Aug. 21, 2014, 9:11 p.m.) > > > Review request for KDE Base Apps and KDE Utils. > > > Bugs: 338414 > http://bugs.kde.org/show_bug.cgi?id=338414 > > > Repository: ark > > > Description > --- > > This patch implements the "Add to archive" option, which is shown when a user > drags and drops files onto an existing archive. > > > See also: > https://git.reviewboard.kde.org/r/119892 > https://bugs.kde.org/show_bug.cgi?id=338414 > > > Diffs > - > > app/ark_dndaddtoarchive.desktop.cmake PRE-CREATION > app/CMakeLists.txt f1ef01b > app/addToArchiveDndPlugin.h PRE-CREATION > app/addToArchiveDndPlugin.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/119890/diff/ > > > Testing > --- > > > Thanks, > > Arjun AK > >
Re: Freeze on nested eventloops (QFileDialog::getOpen*)
On Wed, Jun 24, 2015 at 9:52 AM, Milian Wolff m...@milianw.de wrote: Hm, so maybe related to https://git.reviewboard.kde.org/r/124128/ ? Vishesh, did you also see similar freezes? I didn't actually get the freezes, but David Edmunson was getting them and complaining about it. I decided to fix it.
Re: KSyCoca, Thread safety, and Cache invalidation
On Sat, Jun 13, 2015 at 9:26 PM, David Faure fa...@kde.org wrote:
3 bis:
I assume the threads without an event loop have some way to get tasks, right?
So when the gui thread gets notified about ksycoca changes, it should post a
task to these threads-with-no-eventloop which says sycoca has changed.
It's ok if they keep using an old instance meanwhile (the mmap'ed file uses
refcounting in the kernel).
When the thread finally gets the task it can call
KSycoca::notifyDatabaseChanged (it's a private slot, use
QMetaObject::invokeMethod for now, if it works we can make it public).
I've tried a hackish way to communicate with the other threads. See
attached patch.
This doesn't quite work since KSysCocaPrivate::checkDatabase isn't
always called before finding an entry. Resetting the db in findEntry
leads of crashes cause the state of the stream isn't as expected by
the factory.
Any tips?
--
Vishesh Handa
commit 3f7fab8756db5e1773af862eda6dd9322b49af22
Author: Vishesh Handa m...@vhanda.in
Date: Fri Jun 19 21:44:15 2015 +0200
Hookup databaseChanged signals to other threads
When the db changes, we are notified via dbus. This calls a slot, which
which closes the db. This works out well for when each of those threads
has an event loop so that the slot can be called, but otherwise, the db
never gets updated.
We now mark the db as invalid for all threads from the thread that
receieves it.
THIS DOES NOT WORK! I'm not sure how the db recreation logic works.
diff --git a/src/sycoca/ksycoca.cpp b/src/sycoca/ksycoca.cpp
index 32d1689..115a80c 100644
--- a/src/sycoca/ksycoca.cpp
+++ b/src/sycoca/ksycoca.cpp
@@ -34,6 +34,8 @@
#include QtCore/QFile
#include QtCore/QFileInfo
#include QtCore/QBuffer
+#include QMutex
+#include QMutexLocker
#include QProcess
#include QDBusConnection
#include QDBusConnectionInterface
@@ -89,6 +91,7 @@ KSycocaPrivate::KSycocaPrivate()
updateSig(0),
sycoca_size(0),
sycoca_mmap(0),
+ dbInvalid(false),
m_mmapFile(0),
m_device(0)
{
@@ -167,7 +170,15 @@ public:
KSycoca *sycoca()
{
if (!m_threadSycocas.hasLocalData()) {
-m_threadSycocas.setLocalData(new KSycoca);
+KSycoca* sycoca = new KSycoca;
+QObject::connect(sycoca, QObject::destroyed, [](QObject* obj) {
+QMutexLocker lock(s_allSycocasMutex);
+s_allSycocas.removeOne(qobject_castKSycoca*(obj));
+});
+
+m_threadSycocas.setLocalData(sycoca);
+QMutexLocker lock(s_allSycocasMutex);
+s_allSycocas sycoca;
}
return m_threadSycocas.localData();
}
@@ -176,10 +187,15 @@ public:
m_threadSycocas.setLocalData(s);
}
+static QListKSycoca* s_allSycocas;
+static QMutex s_allSycocasMutex;
private:
QThreadStorageKSycoca * m_threadSycocas;
};
+QListKSycoca* KSycocaSingleton::s_allSycocas;
+QMutex KSycocaSingleton::s_allSycocasMutex;
+
Q_GLOBAL_STATIC(KSycocaSingleton, ksycocaInstance)
// Read-only constructor
@@ -322,6 +338,7 @@ void KSycocaPrivate::closeDatabase()
{
delete m_device;
m_device = 0;
+dbInvalid = false;
// It is very important to delete all factories here
// since they cache information about the database file
@@ -359,6 +376,17 @@ bool KSycoca::isChanged(const char *type)
void KSycoca::notifyDatabaseChanged(const QStringList changeList)
{
+// We tell all the other threads that their db is invalid so it can be reloaded later
+// This is important because the other threads might not have event loops running and
+// therefore will get the dbus signal which calls this slot
+QMutexLocker lock(KSycocaSingleton::s_allSycocasMutex);
+for (KSycoca* ksycoca : KSycocaSingleton::s_allSycocas) {
+qDebug() MARKING;
+ksycoca-d-dbInvalid = true;
+}
+qDebug() ---;
+lock.unlock();
+
d-changeList = changeList;
//qCDebug(SYCOCA) QThread::currentThread() got a notifyDatabaseChanged signal changeList;
// kbuildsycoca tells us the database file changed
@@ -417,12 +445,13 @@ KSERVICE_EXPORT bool kservice_require_kded = true;
// and past the version number.
bool KSycocaPrivate::checkDatabase(BehaviorsIfNotFound ifNotFound)
{
-if (databaseStatus == DatabaseOK) {
+if (databaseStatus == DatabaseOK !dbInvalid) {
if (checkVersion()) { // we know the version is ok, but we must rewind the stream anyway
return true;
}
}
+qDebug() CLOSING DB ... ;
closeDatabase(); // close the dummy one
const QString KDED_SERVICE_NAME=QStringLiteral(org.kde.kded5);
@@ -434,9 +463,10 @@ bool KSycocaPrivate::checkDatabase(BehaviorsIfNotFound ifNotFound)
qAppName() == QLatin1String(kbuildsycoca5);
// Check if new database already available
-if ((kdedRunning || !kservice_require_kded) openDatabase(ifNotFound
KSyCoca, Thread safety, and Cache invalidation
Hey David There is a bug in KRunner that new applications do not show up unless KRunner is restarted. The problem is as follows - * Every thread has its own KSysCoca instance * Each KSysCoca interface listens for a dbus signal on when it should update its db * Without an event loop, dbus signals are never received. Since KRunner runs each runner in a separate thread without an event loop, the threads which the application search runner runs on are never updated. And newer applications never show up. Possible ways of fixing this - 1. Modify ThreadWeaver to run a event loop when threads aren't being used. 2. Use only a single KSyCoca instance instead of 1 instance per thread, and add loads of locking code. 3. The gui thread on receiving the dbus signal updates its db as well as the database of all other threads. This is slightly complex and would require locking code similar to (2) since the other threads could be in the process of using KSycoca. 4. Modify KSycoca so that it re-opens the db on each query. This probably seems very expensive, but it might not be with the memory mapped backend. 5. Modify KRunner application runner to always reload the db before each query. 6. Modify the application runner to only run in the gui thread. I'm not quite sure on how to go about this. Do you have any suggestions? I'm leaning towards (3), but the locking code is scary. Regards Vishesh Handa
Re: Strigi usage in KF5 world
On Sun, Apr 19, 2015 at 9:58 PM, Albert Astals Cid aa...@kde.org wrote: For Strigi, i'd be voting to just enable it again and since noone else seems to care i'd say i win :D I also think we should enable it again. -- Vishesh Handa
Re: Moving User Manager back to playground
On Thu, Apr 9, 2015 at 9:08 PM, Marco Martin notm...@gmail.com wrote: uuh, did it end up in the release then? Only during the beta. I think this was for Kubuntu. The plan as discussed during the Plasma sprint was to the move the user-manager code into plasma-desktop, and merge it into the accounts kcms. The user-manager repository may never actually get a release. -- Vishesh Handa
Moving User Manager back to playground
Hey guys It seems that 'user-manager' was moved into the kde/workspace subdirectory a couple of months ago, even though it was clearly blocked during the review process in kde-core-devel. I'm going to ask the system-admin request to move it back there. If you have any objections please let me know. -- Vishesh Handa
Re: Moving User Manager back to playground
On Thu, Apr 9, 2015 at 10:02 PM, Jonathan Riddell j...@jriddell.org wrote: Ug please don't. It'll mess up my release scripts and the translations. Stuff in playground shouldn't get releases but this does get beta releases as part of Plasma so Plasma is the obvious place to have it. I see no problem that gets solved by moving it. To make it very clear it isn't part of Plasma. It even has a release blocking bug[1] (which was brought up during the review) and therefore cannot be released. [1] https://bugs.kde.org/show_bug.cgi?id=342631 -- Vishesh Handa
Re: Moving User Manager back to playground
On Thu, Apr 9, 2015 at 10:45 PM, Jonathan Riddell j...@jriddell.org wrote: On Thu, Apr 09, 2015 at 10:31:41PM +0200, Vishesh Handa wrote: On Thu, Apr 9, 2015 at 10:02 PM, Jonathan Riddell j...@jriddell.org wrote: Ug please don't.A It'll mess up my release scripts and the translations.A Stuff in playground shouldn't get releases but this does get beta releases as part of Plasma so Plasma is the obvious place to have it.A I see no problem that gets solved by moving it. To make it very clear it isn't part of Plasma. It even has a release blocking bug[1] (which was brought up during the review) and therefore cannot be released. [1]A https://bugs.kde.org/show_bug.cgi?id=342631 It is part of Plasma, that's why it was moved there and why it is released as part of Plasma. It's only released with betas for now in the same way as touchpad-kcm was and plasma mediacenter is. Why is it part of Plasma? It should have never been moved to the `kde/workspace` section since issues were brought up during the review. -- Vishesh Handa
Re: Strigi usage in KF5 world
On Wed, Apr 8, 2015 at 2:12 AM, Michael Pyne mp...@kde.org wrote: I was honestly surprised we still used it when I first built KF5. I suspect it's because it was easier to port strigi (which is after all not strongly tied to a toolkit) than to port its users, not because of a positive decision to keep using strigi. But I don't know, I haven't done a lot of KF5 porting... We're not using it in KF5. We're using it in kdelibs4support. -- Vishesh Handa
Re: KDE Telepathy has an unreleased dependency
On Wed, Feb 25, 2015 at 6:39 PM, Martin Klapetek martin.klape...@gmail.com wrote: As I said it's not even being used right now, so imho would be fine if it got removed/disabled altogether. Also, it will never work. Baloo KF5, has no knowledge about emails. That code also uses Akonadi APIs. -- Vishesh Handa
Re: Plasma 5.2 bits for kdereview
On Thu, Jan 8, 2015 at 11:54 AM, Kåre Särs kare.s...@iki.fi wrote: Is there something stopping Baloo from becoming a thin wrapper around the native solutions when used on those platforms? (Except man power ;) /Kåre Yup. Mostly man power, and that I don't care and/or have access to the other platforms. -- Vishesh Handa
Re: Plasma 5.2 bits for kdereview
On Thu, Jan 8, 2015 at 11:52 AM, Ian Wadham iandw...@gmail.com wrote: On 08/01/2015, at 9:40 PM, Vishesh Handa wrote: On Thu, Jan 8, 2015 at 7:39 AM, Ian Wadham iandw...@gmail.com wrote: - I don't think Windows has anything like Baloo or KWallet, but Apple OS X certainly has, and has had for years. We, on the KDE-Mac list, are starting to integrate KWallet and Apple's Keychain app, but Baloo is still an unknown quantity, esp. re how hard-wired it is into KDE apps. Side note: Windows has really good search capabilities. I have not seen or heard of them, and I go to a PC Users' Group regularly. Which version of Windows? Maybe 8? I know windows 7 has it. I've only mostly looked at it from the technical documentation - http://msdn.microsoft.com/en-us/library/bb787584(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/cc678933(v=vs.85).aspx Plus the NTFS file system has a the USN Journal which would allow you to know what has changed since last run. That directly caters to file indexers. Also, they have really good file change notification systems. Unlike Linux. They actually have many more features than Mac's spotlight, but they lack the marketing and usability of spotlight. Baloo would be a bad fit on both windows and mac. I am sad to hear that. It would be nice if apps from KDE could keep indexing terms in the same place as Spotlight. Baloo is good in comparison to Spotlight. We mostly lack from the kernel side. When I said that Baloo would be a bad fit on Windows/Mac - I meant that it would work worse than the existing solutions, because it doesn't tap into the kernels and filesystem APIs that are available on Windows/Mac. Also, people often write extra indexers on those platforms which it would not get access to. -- Vishesh Handa
Re: Plasma 5.2 bits for kdereview
On Fri, Jan 9, 2015 at 5:12 PM, Vishesh Handa m...@vhanda.in wrote: Yup. Mostly man power, and that I don't care and/or have access to the other platforms. Minor correction: It's more about not having the motivation. Less about access. I actually do own a mac. -- Vishesh Handa
Re: Plasma 5.2 bits for kdereview
On Thu, Jan 8, 2015 at 7:39 AM, Ian Wadham iandw...@gmail.com wrote: - I don't think Windows has anything like Baloo or KWallet, but Apple OS X certainly has, and has had for years. We, on the KDE-Mac list, are starting to integrate KWallet and Apple's Keychain app, but Baloo is still an unknown quantity, esp. re how hard-wired it is into KDE apps. Side note: Windows has really good search capabilities. They actually have many more features than Mac's spotlight, but they lack the marketing and usability of spotlight. Baloo would be a bad fit on both windows and mac. -- Vishesh Handa
Re: Plasma 5.2 bits for kdereview
On Fri, Dec 19, 2014 at 6:46 PM, Luigi Toscano luigi.tosc...@tiscali.it wrote: User-manager frameworks port (it overlaps a little with account details kcm but is mostly an admin tool) https://projects.kde.org/projects/playground/base/user-manager kuser replacement? This one is problematic. We cannot just ship both. They both overall to a large extent however the and user-manager doesn't actually write to the kde config files for setting the full name + email. We use that for bugzilla reports, kdevelop templates and a few other cases. Also there is that hold one-bullet/vs-three/vs-none of password dialogs. I'm fairly certain that is broken, but I need to test it out. -- Vishesh Handa
Re: Gwenview maintainership
Perhaps you could discuss the details on the list? I'm quite interested in these details, specially since I was fooling around on a gallery application based on the VDG mockups [1] [1] https://forum.kde.org/viewtopic.php?f=285t=122869 On Wed, Oct 15, 2014 at 8:56 AM, Aurélien Gâteau agat...@kde.org wrote: On Tue, Oct 14, 2014, at 22:10, Lukáš Tinkl wrote: Dne 14.10.2014 v 17:51 Aurélien Gâteau napsal(a): For the past few months, I haven't been doing any work on KDE projects, and I don't see this changing for now. It's time for me to step down from the projects I maintain. This includes Gwenview. Awesome David Edmundson did the grunt work of porting it to KDE Frameworks 5 (Thanks again David!), but he already has too much on his plate: he can't take over Gwenview. I am therefore looking for a new maintainer. If you are interested, please get in touch. I would be more than happy to guide you through the code to get you started. Some parts of Gwenview user interface (as well as inner plumbing) are getting a bit dated, so it would be wonderful if you could get in touch with the VDG to give Gwenview the visual refresh it deserves. Aurélien Hi, as I did quite some fixes recently, I'd be happy to take over the maintainership from you. Thanks for all the hard work, Gwenview is fun to hack on! Thanks for volunteering Lukáš. I am happy to leave Gwenview in your hands. Let's discuss the details of list. Aurélien -- Vishesh Handa
Re: Gwenview maintainership
On Wed, Oct 15, 2014 at 1:28 PM, Aurélien Gâteau agat...@kde.org wrote: With details I mean adminstrivia like handing over mailing list, bugzilla, reviewboard and friends, not much about the future of Gwenview itself. Ah. Alright. -- Vishesh Handa
Re: SDDM-KCM In Review
Hey David. None of these are blockers. Just stuff I noticed. * There is this strange ACKNOWLEDGEMENTS file * themeconfig.cpp ** The delegate seems to have a fixed size of 128x128. This might not be ideal for hidpi screens ** ThemeConfig::dump - Extra indendation * thememodel.cpp - KStandardDirs and KGlobal headers are not required * usersmodel.cpp - The coding style is quite different
Re: libkface
Hey Tobias Some comments about the code - 1. The code seems to be licensed under GPL. In order to make it into a framework, it will need to be re-licensed. This library seems like an ideal candidate for becoming a framework. 2. The copyright header seems to say Part of the Digikam Project. You may want to change that. 3. There is an empty TODO file 4. The coding style uses seems a little unorthdox. Could you perhaps add a link to where one can know what style is being followed? Maybe this could go in the README file. 5. Identity ABI - The Identity class seems to be missing a d pointer. 6. From what I understand, facial recognition is not particularly cheap. However, the APIs appear to be blocking. What is the correct way to use them? Spawn a new thread? Run under a QRunnable? On Thu, Sep 25, 2014 at 12:14 PM, Tobias Leupold tobias.leup...@web.de wrote: Hi list! Here's (most of) a mail I recently posted on the kde-graphics-devel mailing list (cf. the whole discussion: http://mail.kde.org/pipermail/kde-graphics-devel/2014-September/000484.html ): I'm from the KPhotoAlbum project. We recently introduced support for face detection and face recognition using libkface (which is currently hosted in extragear/libs, cf. https://projects.kde.org/projects/extragear/libs/libkface/ and http://api.kde.org/extragear-api/libs-apidocs/libkface/libkface/html/index.html). Likely, this will be a part of the next release. Actually, we are the first project apart from Digikam (who initiated and maintain libkface) to use libkface. This leads to a problem: at the moment, libkface is distributed with the Digikam sources. There's an own git repository for the lib's sources in the KDE repositories, but there's no own release. Some distributors (e. g. Gentoo) have an own package for libkface nevertheless, others don't (e. g. Debian). So, at the moment, we would have to include libkface in our sources, as Digikam does (which would lead to collisions if both KPA and Digikam would be installed and is perhaps not a good idea) or we would have to pull the full Digikam package as a dependency if the user wants libkface support. Both solutions don't seem to be nice. Thus, Gilles Caulier from Digikam suggested to move libkface into kdegraphics/libs, so that it will be included into the normal KDE release cycle and will be independent of Digikam (Digikam apparently can't manage a separate lib release itself, the original discussion can be found at http://mail.kde.org/pipermail/digikam-devel/2014-September/075737.html). The discussion on kde-graphics-devel finished with the statement this had to be determined by kde-core-devel. So what do you think? Yours, Tobias -- Vishesh Handa
Closing the kde-core-devel mailing list
Hello people Random Idea: How about we close the k-c-d mailing list? It's main purpose used to be to discuss kdelibs changes, but now since we have kde-frameworks, the mailing list seems less useful. We already have kde-devel for other generic kde stuff. -- Vishesh Handa
Re: 4.13.3 tarballs are available for packagers
On Sat, Jul 12, 2014 at 8:53 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 20:11:35, Vishesh Handa va escriure: On Sat, Jul 12, 2014 at 5:28 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 17:24:30, Albert Astals Cid va escriure: Note that baloo unit tests are not passing and if it's not fixed (+ package respun) before tuesday it won't be part of the release. I mean http://build.kde.org/view/KDE%20SC%20stable/job/baloo_stable/ is not green. I'm really not sure why the test is failing. It is passing perfectly on multiple machines that I've tried it out. It just seems to be jenkins. I'll try to figure it out, otherwise I'll disable the test. I specially wrote the test when I was fixing a bug for 4.13.3. Disabling the test doesn't really seem like a good idea. Can't you just add more debug to see what's wrong? Test fixed. It was a problem with the test, not with the code.
Re: 4.13.3 tarballs are available for packagers
On Sat, Jul 12, 2014 at 5:28 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 12 de juliol de 2014, a les 17:24:30, Albert Astals Cid va escriure: Note that baloo unit tests are not passing and if it's not fixed (+ package respun) before tuesday it won't be part of the release. I mean http://build.kde.org/view/KDE%20SC%20stable/job/baloo_stable/ is not green. I'm really not sure why the test is failing. It is passing perfectly on multiple machines that I've tried it out. It just seems to be jenkins. I'll try to figure it out, otherwise I'll disable the test. I specially wrote the test when I was fixing a bug for 4.13.3. Cheers, Albert Cheers, Albert El Divendres, 11 de juliol de 2014, a les 20:40:05, Torgny Nyblom va escriure: Hi, tarballs for KDE SC 4.13.3 and kde-workspace 4.11.11 are available at the usual location. /Regards Torgny Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: KF5 Maintainers: Please get ready for release
On Sunday, April 27, 2014 12:32:25 AM Kevin Ottens wrote: No maintainer: - krunner (porting aid) I'm willing to maintain krunner. -- Vishesh Handa
Re: Review Request 117789: Optimize word count in PlainTextExtractor.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117789/#review56900 --- Ship it! Thanks! :) - Vishesh Handa On April 26, 2014, 1:15 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117789/ --- (Updated April 26, 2014, 1:15 p.m.) Review request for kdelibs and Vishesh Handa. Repository: kfilemetadata Description --- Optimize word count in PlainTextExtractor. Regular expressions are notoriously slow. Implementing a simple word-count directly in C++ is much faster, as shown by the benchmark: Before: 702.0 msecs per iteration (total: 7,020, iterations: 10) After: 125.5 msecs per iteration (total: 1,256, iterations: 10) Make the plaintext extractor benchmark more meaningful. It now operates on a larger file and uses QBENCHMARK to actually get some data. Diffs - autotests/indexerextractortests.cpp 1cb8e65da7d764eab1923054659ae5841104de2d src/extractors/plaintextextractor.cpp 536e02d843f24dbbc19035029896b9e696e8b302 Diff: https://git.reviewboard.kde.org/r/117789/diff/ Testing --- Thanks, Milian Wolff
Re: Review Request 116953: Create a ksysguard kded module
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116953/ --- (Updated April 4, 2014, 1:26 p.m.) Status -- This change has been discarded. Review request for kde-workspace and John Tapsell. Repository: kde-workspace Description --- Create a ksysguard kded module This module is responsible for launching the system activity dialog which krunner used to spawn on pressing Ctrl + Escape. The KSystemActivityDialog has been moved from kde-workspace/krunner/ Diffs - krunner/ksystemactivitydialog.h d72bebd krunner/ksystemactivitydialog.cpp 5c4bcac ksysguard/CMakeLists.txt 35f11f3 ksysguard/kded/CMakeLists.txt PRE-CREATION ksysguard/kded/kded_ksysguard.desktop PRE-CREATION ksysguard/kded/kdedksysguard.h PRE-CREATION ksysguard/kded/kdedksysguard.cpp PRE-CREATION ksysguard/kded/ksystemactivitydialog.h PRE-CREATION ksysguard/kded/ksystemactivitydialog.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116953/diff/ Testing --- Thanks, Vishesh Handa
Re: Tests still failing in 4.13
On Monday, March 31, 2014 01:42:01 AM Albert Astals Cid wrote: Hello people, at the moment we have various 4.13 projects failing. Hello I am also open to be convinced that the test is right and that it's unfixable to run correctly on jenkins, but make sure you are really convincing if you resort to that ;-) nepomuk-core (1 failing test) http://build.kde.org/view/KDE%20SC%20stable/job/nepomuk-core_stable/323/tes tReport/ The failing test is actually passing, but setting up the entire test environment and running the test doesn't always seem to work. Could we have an exception for this? I'm not too inclined on trying to fix it considering that there have been no changes in Nepomuk for 4.13 -- Vishesh Handa
Re: Help splitting kde-workspace
On Sunday, March 30, 2014 01:24:16 PM Àlex Fiestas wrote: Alternatively we could use grafts like we have done with frameworks. +1 If it works for frameworks, it should work for us. -- Vishesh Handa
Re: Moving Milou to Extragear
Vishesh HandaOn Friday, February 14, 2014 01:09:19 PM wrote: On Thursday, February 13, 2014 11:28:40 AM Burkhard Lück wrote: That loads the translation catalog, which also contains messages from the plasmoid outside the library. Apparently that happens early enough at runtime (at least I see the catalog is loaded running milou in plasmoidviewer in locale x-test), so even messages used only in the plasmoid are translated. Your plasmoid tries to load a catalog named plasma_applet_milou_applet via plasmoid/applet.h:60:K_EXPORT_PLASMA_APPLET(milou_applet, Applet), but you extract to milou, so this catalog does not exist. But then the milou catalog would be loaded so the translations should be there, right? If not, what would be the correct way of fixing this? One option which I can think of is extracting the translations to plasma_applet_milou_applet, and updating the KCatalogLoader in the case the library is used without the applet. I've changed the catalog name to plasma_applet_milou_applet. That should work. I'm going to request the move to extragear on Monday. -- Vishesh Handa
Review Request 116953: Create a ksysguard kded module
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116953/ --- Review request for kde-workspace and John Tapsell. Repository: kde-workspace Description --- Create a ksysguard kded module This module is responsible for launching the system activity dialog which krunner used to spawn on pressing Ctrl + Escape. The KSystemActivityDialog has been moved from kde-workspace/krunner/ Diffs - krunner/ksystemactivitydialog.h d72bebd krunner/ksystemactivitydialog.cpp 5c4bcac ksysguard/CMakeLists.txt 35f11f3 ksysguard/kded/CMakeLists.txt PRE-CREATION ksysguard/kded/kded_ksysguard.desktop PRE-CREATION ksysguard/kded/kdedksysguard.h PRE-CREATION ksysguard/kded/kdedksysguard.cpp PRE-CREATION ksysguard/kded/ksystemactivitydialog.h PRE-CREATION ksysguard/kded/ksystemactivitydialog.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116953/diff/ Testing --- Thanks, Vishesh Handa
Re: Moving Baloo forward
On Thursday, February 20, 2014 08:58:48 AM GEO wrote: First of all: I am totally for xattr, thank you Vishesh for the great idea! Thanks, though the idea was Simeons. I just implemented some parts of it :) -- Vishesh Handa
Re: Moving Milou to Extragear
On Thursday, February 13, 2014 11:32:04 AM Lukáš Tinkl wrote: Then there had been another problem with the preview plugins which I just fixed as well Thanks Lukas! -- Vishesh Handa
Re: Moving Milou to Extragear
On Thursday, February 13, 2014 11:28:40 AM Burkhard Lück wrote: That loads the translation catalog, which also contains messages from the plasmoid outside the library. Apparently that happens early enough at runtime (at least I see the catalog is loaded running milou in plasmoidviewer in locale x-test), so even messages used only in the plasmoid are translated. Your plasmoid tries to load a catalog named plasma_applet_milou_applet via plasmoid/applet.h:60:K_EXPORT_PLASMA_APPLET(milou_applet, Applet), but you extract to milou, so this catalog does not exist. But then the milou catalog would be loaded so the translations should be there, right? If not, what would be the correct way of fixing this? One option which I can think of is extracting the translations to plasma_applet_milou_applet, and updating the KCatalogLoader in the case the library is used without the applet. -- Vishesh Handa
Re: Moving Milou to Extragear
On Wednesday, February 12, 2014 11:56:27 PM Albert Astals Cid wrote: El Dimarts, 11 de febrer de 2014, a les 11:55:01, Vishesh Handa va escriure: Hello people I've been developing Milou for quite some time now and I think it would be best to move it into extragear so that a release can be made sometime after the 4.13 release. Milou is a dedicated search plasmoid for Baloo. Here is a nice screenshot [1]. It also supports previews for certain file types, specially emails. It implements its own form of runners called sources. The main source is the Baloo source along with one for applications. On moving to KF5 its concept of sources will be dropped and it will directly use the runners. The needed features will be added to the krunner framework. I could really use a review for the QML code, hence the plasma-devel cc. Why some i18n calls have a space at the end? Fixed I'd also say that your catalog isn't getting loaded (i.e. your catalog name is wrong). Is it? Messages.sh #! /usr/bin/env bash $XGETTEXT `find . -name *.cpp -o -name *.qml` -o $podir/milou.pot And in lib/abstractsource.cpp 26:static const KCatalogLoader loader(milou); What would need to be changed? -- Vishesh Handa
Re: Moving Milou to Extragear
On Wednesday, February 12, 2014 11:57:56 PM Albert Astals Cid wrote: Also you can optimize qDeleteAll(m_mapping.values()); to qDeleteAll(m_mapping); Thanks. Fixed -- Vishesh Handa
Re: KDE Review: Move LabPlot to extragear.
Hey I've just taken a cursory glance. Some things that I noticed - 1. The recommended mailing list is sourceforge - Do you want to move to KDE? I'm not sure if this is required by the manifesto or not. We do enforce the usage of kde-infrastructure 2. AUTHORS - Do you really need to obfuscate the email addresses? Anyone can easily fetch them from the copyright headers or git logs. 3. You're using qt4_wrap_cpp in your CMakeLists.txt, how about using automoc? You can do that auto-magically by including kde4 defaults in your CMakeLists - include(KDE4Defaults) 4. kdefrontend/History.h - It has a class Project; declaration before the include file. Was this intentional? 5. You're calling kde4_update_iconcache() in the src/CMakeLists.txt file, not the icons/CMakeLists.txt file? Both options work out fine. 6. You have an admin/README.svn file. Perhaps that is now out of date? Also, whoa! That's a lot of code. I'll look more into the actual code later. -- Vishesh Handa
Re: Moving Milou to Extragear
On Tuesday, February 11, 2014 11:48:44 PM Albert Astals Cid wrote: Repo name? Oops. It's called milou. Clone it via the standard - kde:milou -- Vishesh Handa
Moving Milou to Extragear
Hello people I've been developing Milou for quite some time now and I think it would be best to move it into extragear so that a release can be made sometime after the 4.13 release. Milou is a dedicated search plasmoid for Baloo. Here is a nice screenshot [1]. It also supports previews for certain file types, specially emails. It implements its own form of runners called sources. The main source is the Baloo source along with one for applications. On moving to KF5 its concept of sources will be dropped and it will directly use the runners. The needed features will be added to the krunner framework. I could really use a review for the QML code, hence the plasma-devel cc. -- Vishesh Handa [1] http://vhanda.in/milou.png
Re: Review Request 115371: Remove strigi usages from kde-runtime
On Jan. 29, 2014, 10:45 p.m., Vishesh Handa wrote: If you're removing it from the CMakeLists then please remove the kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. You may want to grep through kde-runtime for all uses of strigi. (Ignore the nepomuk ones, that's just an old variable name) Hrvoje Senjan wrote: If you're removing it from the CMakeLists then please remove the kde-runtime/kioslave/trash/trashthroughanalyzer.* files as well. Already done in the patch ;-) You may want to grep through kde-runtime for all uses of strigi. Nothing else was using it =) Sorry. I'm blind :) Ship it! - Vishesh --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/#review48573 --- On Jan. 28, 2014, 11:04 p.m., Hrvoje Senjan wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115371/ --- (Updated Jan. 28, 2014, 11:04 p.m.) Review request for KDE Runtime and Vishesh Handa. Repository: kde-runtime Description --- Strigi is used only for trashanalyzer, which isn't installed since 2007 ;-) so i removed it also. Diffs - CMakeLists.txt 312f42f kioslave/trash/CMakeLists.txt ddf0ae0 kioslave/trash/tests/CMakeLists.txt 651f25d kioslave/trash/trashthroughanalyzer.cpp df0eb87 Diff: https://git.reviewboard.kde.org/r/115371/diff/ Testing --- Builds. Thanks, Hrvoje Senjan
Re: Moving KFIleMetadata into KDE SC
On Wednesday 22 January 2014 19:15:01 Àlex Fiestas wrote: · I would add the url and mimetype in the cto, plugins should not be able to change it anyway. Fixed · Documentation needs improvement, specially ExtractionResult (making it clear that you should inherit it in order to use the lib). Fixed. · ExtratorPlugin::mimetypes is pure virtual yet it has an implementation Fixed. · Add context to i18n in typeinfo Fixed Also you might want to use Qt translation libs so kfilemetadata becomes a Qt only lib, that might help other desktops/apps to use it (in kf5 you can use k18n if you want). Sticking with i18n for now. Once this is fix, yo get +1 from me ! Thanks -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC (documentation and ExtractionResult)
On Wednesday 22 January 2014 00:23:45 Albert Astals Cid wrote: El Divendres, 17 de gener de 2014, a les 18:03:31, Vishesh Handa va escriure: Hey guys I should have posted this with the Baloo thread, but since I did not - WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their own indexing library. This code was part of nepomuk-core. With Baloo, this code has been migrated into its own repository called kfilemetadata. I'm hoping to make it into its own framework some point in the future. I would like to move this code into KDE SC along with Baloo. None of the code is new. It has all been taken from neopmuk-core. The only change is that the indexers no longer use the ontologies. Can you have a look at virtual void extract(ExtractionResult* result) = 0; It seems to me that the documentation is wrong, it lists lots of params. Fixed. Also i tried looking at ExtractionResult and without documentation i'm not sure i'd be able to use it, could you add some docu and/or example? I've improved the documentation to a certain extent. I'll try adding an actual example later. Maybe once I've figured out the property system (see below) Also I was wondering what is if we could move from all those strings to enums? I mean result-add(copyright, it.value()); is a bit hard, since whatever reads the result has to know it has to query for copyright. I've been trying to build a property system which would incorporate - 1. Actual names instead of strings 2. Property ranges. Eg - height should be an integer 3. Property name translations - The way translations are currently handled is ugly. It works, but it is ugly. 4. Should the property be globally indexed - Some properties should not globally indexed, and should only appear when the user searches for that exact property. RDF provided a nice way to specifying all of this, but I'm not too keen on using RDF. In the end, I may just use enums, but for now strings it is. Also i am wondering why addType is virtual and append/add are pure virtual. I thought the derived classes may not care about the type. I've changed it to pure virtual to be more consistent. Cheers, Albert Thanks for looking into this Albert. -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC
On Wednesday 22 January 2014 00:16:05 Albert Astals Cid wrote: El Dimarts, 21 de gener de 2014, a les 11:56:33, Vishesh Handa va escriure: On Monday 20 January 2014 22:38:52 Albert Astals Cid wrote: Also make sure all the classes have a d-pointer in case they need to be expanded in the future you can keep ABI. Fixed. Maybe even add one to ExtractorPlugin in case you need to add stuff in there later? I didn't think I would need it in the future, but you're right. It's better to be safe. What about moving ExtractorPluginManager::allExtractors to the private? Fixed. -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC (documentation and ExtractionResult)
On Wednesday 22 January 2014 13:09:58 David Edmundson wrote: Add COPYING file Fixed ExtractorPluginManager::fetchExtractors seems odd to me. If it can't find any plugins it searches for all plugins that start the same prefix. I assume it's designed so I can have a plugin with the mimetype audio/ that will still match the file mimetype audio/mp3 But this means that if I add a special new plugin with the mimetype audio/mp3 the original plugin will stop running? Given you're trying to build a list of all valid plugins, is that meant to happen? Yes. I've added the relevant documentation. -- ExtractionResult: Having setInputUrl / setInputMimetype public in a way which can be set by the plugins seems wrong; personally I'd put the two in the constructor. Fixed -- We should document the list of names of properties that can be extracted. Some things are in lowerCamelCase i.e wordCount author except for the eviv plugin which is in the form: Exif.Image.Make and the odf extractor which is in the form dc:title to me it seems fairly random. Fixed. Added a proper property and type system. -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC
On Monday 20 January 2014 22:37:12 Albert Astals Cid wrote: Please have a look at the const-ness of the methods, there's lots of geters that are non const. Fixed -- Vishesh Handa
Re: Moving Baloo forward
On Tuesday 21 January 2014 12:37:14 Jaime wrote: 2014/1/21 Vishesh Handa m...@vhanda.in On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. I'm just curious, the additional database uses the filename or a hash of the file content as the key for the metadata? Currently we have one sqlite db which is responsible for mapping file urls - integer identifiers. We also install inotify watches on EVERY folder in your home directory. When a file moves the db is updated. This unique integer identifier (henceforth called file id), is used to map the indexed data to the file. When this alternate database will be used to store tags, ratings, etc instead of xattr, at that time this file id will be used to uniquely identify the file. -- Vishesh Handa
Re: Moving Baloo forward
On Tuesday 21 January 2014 13:06:40 viv...@gmail.com wrote: On 01/21/14 11:50, Vishesh Handa wrote: On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. I disagree. It'll be easier to backup / restore xattr than it would be with that database. Additionally, a LOT of tools do respect extended attributes (cp with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt I can implement it with the extra database as well. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. So we agree to disagree ;) especially on the never lost part, when moved with kio they will be lost, when using unix command line programs, and without special arguments they will be lost. When copied not moved. Most important of all they are normally hidden, more hidden than a .dot file, an additional database, even a .dot file is much more easy to remember. $ echo Hello a $ attr -s simple.attibute -V test for xattr ./a Attribute simple.attibute set to a 14 byte value for ./a: test for xattr $ kioclient cp a b $ attr -l b empty kio can be modified :) $ cp a b $ attr -l b empty $ cp -a a b $ attr -l b Attribute simple.attibute has a 14 byte value for b $ rm b $ rsync a b $ attr -l b empty $ rsync -X a b $ attr -l b Attribute simple.attibute has a 14 byte value for b Maybe we could push distros to enable the -a flag by default? Mac does it by default. -- Vishesh Handa
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 forward
On Tuesday 21 January 2014 12:32:29 Todd wrote: Would it be possible to store the metadata inside files that support it (like images or music files) and use xattrs only for files that don't have their own internal metadata format? Well, anything is possible. Someone would just need to implement it. We had wanted to do something similar during the Nepomuk days as well, but it didn't quite materialize. -- 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 forward
On Sunday 19 January 2014 14:44:01 Albert Astals Cid wrote: http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. Added Found in http://lxr.kde.org/search?filestring=string=nepomuk Can you please find out about them and add the information? Not found there but found by grepping my 4.11 branch of kde-workspace, nepomuksearch runner, containmentactions/switchactivity, dataengines/metadata. I am interested what is your plan for kde-workspace since it's frozen at 4.11. I will provide a Baloo runner. The metadata dataengine can die. It uses Strigi internally, and just uses Nepomuk for tags, ratings and comments. If someone really has a huge objection then I can provide a similar Baloo dataengine. The SwitchActivity does not use Nepomuk. It just has a variable called useNepomuk which doesn't do anything with Nepomuk. Also are you sure you can finish all that in 5 weeks? I can finish all the applications that are part of KDE SC for sure. This involves - 1. Dolphin 2. KDEPIM 3. GwenView The rest, no. I doubt I can do it all. -- Vishesh Handa
Re: Moving Baloo forward
On Monday 20 January 2014 23:17:26 Albert Astals Cid wrote: El Dilluns, 20 de gener de 2014, a les 19:08:41, Vishesh Handa va escriure: On Sunday 19 January 2014 14:44:01 Albert Astals Cid wrote: http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. Added Found in http://lxr.kde.org/search?filestring=string=nepomuk Can you please find out about them and add the information? Not found there but found by grepping my 4.11 branch of kde-workspace, nepomuksearch runner, containmentactions/switchactivity, dataengines/metadata. I am interested what is your plan for kde-workspace since it's frozen at 4.11. I will provide a Baloo runner. In which repo? The main baloo repo. Unless you think some other repo would be appropriate? The metadata dataengine can die. I'd prefer not to kill stuff from the repo of something we are calling LTS, maybe just add a disabled by default compile flag? Well, I cannot port the metadata engine to Baloo. I can write a new one if required. Cheers, Albert -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC
On Monday 20 January 2014 22:39:30 Albert Astals Cid wrote: El Divendres, 17 de gener de 2014, a les 18:03:31, Vishesh Handa va escriure: Hey guys I should have posted this with the Baloo thread, but since I did not - WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their own indexing library. This code was part of nepomuk-core. With Baloo, this code has been migrated into its own repository called kfilemetadata. I'm hoping to make it into its own framework some point in the future. I would like to move this code into KDE SC along with Baloo. Forgot to ask, which module would that be part of? kde-runtime? Or? kdelibs Cheers, Albert None of the code is new. It has all been taken from neopmuk-core. The only change is that the indexers no longer use the ontologies. -- Vishesh Handa -- Vishesh Handa
Re: Moving KFIleMetadata into KDE SC
On Monday 20 January 2014 22:39:30 Albert Astals Cid wrote: El Divendres, 17 de gener de 2014, a les 18:03:31, Vishesh Handa va escriure: Hey guys I should have posted this with the Baloo thread, but since I did not - WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their own indexing library. This code was part of nepomuk-core. With Baloo, this code has been migrated into its own repository called kfilemetadata. I'm hoping to make it into its own framework some point in the future. I would like to move this code into KDE SC along with Baloo. Forgot to ask, which module would that be part of? kde-runtime? Or? To be clear - I mean under the KDE Libraries. The same place where nepomuk- core, nepomuk-widgets, and activites are. Cheers, Albert None of the code is new. It has all been taken from neopmuk-core. The only change is that the indexers no longer use the ontologies. -- Vishesh Handa -- Vishesh Handa
Re: Moving Baloo forward
On Saturday 18 January 2014 12:53:38 Jonathan Marten wrote: Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. Hey The idea is that in systems which do not support xattr a secondary database will be used to store the information. So, it will be very similar to the situation we had with Nepomuk. I still have to implement this. Regards, Jonathan -- Vishesh Handa
Re: Moving Baloo forward
Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime.
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.
Moving KFIleMetadata into KDE SC
Hey guys I should have posted this with the Baloo thread, but since I did not - WIth KDE SC 4.10, Nepomuk dropped support for Strigi and implemented their own indexing library. This code was part of nepomuk-core. With Baloo, this code has been migrated into its own repository called kfilemetadata. I'm hoping to make it into its own framework some point in the future. I would like to move this code into KDE SC along with Baloo. None of the code is new. It has all been taken from neopmuk-core. The only change is that the indexers no longer use the ontologies. -- Vishesh Handa
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 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 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: Review Request 114717: Language detection in Sonnet
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114717/#review46626 --- README.md https://git.reviewboard.kde.org/r/114717/#comment33272 Empty space src/core/globals.cpp https://git.reviewboard.kde.org/r/114717/#comment33273 The indentation seems slightly strange over here. src/core/guesslanguage.cpp https://git.reviewboard.kde.org/r/114717/#comment33274 Large parts of this file have a different coding style than the conventional one used in other places. Maybe one could choose one coding style and stick to it? src/core/languagefilter.cpp https://git.reviewboard.kde.org/r/114717/#comment33275 You aren't deleting the d pointer. Also, you're not implementing a copy constructor. src/core/languagefilter.cpp https://git.reviewboard.kde.org/r/114717/#comment33276 Space between = This (along with other coding style issues) need to be fixed in many other places all over the file. src/core/settings.cpp https://git.reviewboard.kde.org/r/114717/#comment33278 Does the case matter over here? src/core/settings.cpp https://git.reviewboard.kde.org/r/114717/#comment33277 Nepomuk? :P src/plugins/CMakeLists.txt https://git.reviewboard.kde.org/r/114717/#comment33279 We don't care about Enchant any more? - Vishesh Handa On Dec. 29, 2013, 4:49 a.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114717/ --- (Updated Dec. 29, 2013, 4:49 a.m.) Review request for kdelibs and KDEPIM. Repository: sonnet Description --- I started by merging in the old language detection branch from SVN, while improving it as I went along. One improvement was to use QChar's unicode information instead of shipping our own unicode code point information tables. The old filter class also got replaced with a new tokenizer, which I rewrote most of to simplify. I added kdepim to the reviewers because I remember talking with someone working on PIM stuff on IRC, and he was interested in this (a long time ago, though). Diffs - data/trigrams/ja PRE-CREATION data/trigrams/kk PRE-CREATION data/trigrams/ko PRE-CREATION data/trigrams/ky PRE-CREATION data/trigrams/la PRE-CREATION data/trigrams/lt PRE-CREATION data/trigrams/lv PRE-CREATION data/trigrams/mk PRE-CREATION data/trigrams/mn PRE-CREATION data/trigrams/nb PRE-CREATION data/trigrams/ne PRE-CREATION data/trigrams/nl PRE-CREATION data/trigrams/nr PRE-CREATION data/trigrams/pl PRE-CREATION data/trigrams/ps PRE-CREATION data/trigrams/pt PRE-CREATION data/trigrams/pt_BR PRE-CREATION data/trigrams/pt_PT PRE-CREATION data/trigrams/ro PRE-CREATION data/trigrams/ru PRE-CREATION data/trigrams/sk PRE-CREATION data/trigrams/sl PRE-CREATION data/trigrams/so PRE-CREATION data/trigrams/sq PRE-CREATION data/trigrams/sr PRE-CREATION data/trigrams/ss PRE-CREATION data/trigrams/st PRE-CREATION data/trigrams/sv PRE-CREATION data/trigrams/sw PRE-CREATION data/trigrams/th PRE-CREATION data/trigrams/tl PRE-CREATION data/trigrams/tn PRE-CREATION data/trigrams/tr PRE-CREATION data/trigrams/ts PRE-CREATION data/trigrams/uk PRE-CREATION data/trigrams/ur PRE-CREATION data/trigrams/uz PRE-CREATION data/trigrams/ve PRE-CREATION data/trigrams/vi PRE-CREATION data/trigrams/xh PRE-CREATION data/trigrams/zu PRE-CREATION sonnet.yaml c54f87b src/CMakeLists.txt e79492f src/core/CMakeLists.txt 2f8a184 src/core/backgroundchecker.cpp 8b9e983 src/core/backgroundchecker_p.h PRE-CREATION src/core/backgroundengine.cpp 3a14d34 src/core/backgroundengine_p.h 10f6a27 src/core/client_p.h bd3e416 src/core/filter.cpp e99d332 src/core/filter_p.h 6c7d8c9 src/core/globals.h 0c54c96 src/core/globals.cpp e57450f src/core/guesslanguage.h PRE-CREATION src/core/guesslanguage.cpp PRE-CREATION src/core/languagefilter.cpp PRE-CREATION src/core/languagefilter_p.h PRE-CREATION src/core/loader.cpp ee8db0e src/core/settings.cpp 095eddb src/core/settings_p.h ee2d22c src/core/speller.h 7428339 src/core/speller.cpp 8cc2a1e src/core/textbreaks.cpp PRE-CREATION src/core/textbreaks_p.h PRE-CREATION src/core/tokenizer.cpp PRE-CREATION src/core/tokenizer_p.h PRE-CREATION src/plugins/CMakeLists.txt fc33a97 src/plugins/aspell/kspell_aspellclient.h eadb52a src/plugins/enchant/CMakeLists.txt 817db0c src/plugins/enchant/enchantclient.h 25f62eb src/plugins/hspell/CMakeLists.txt e128cb3 src
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
Moving Baloo and Baloo-widgets into KDE SC
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. -- Vishesh Handa
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: Nepomuk in 4.13 and beyond
On Tuesday 17 Dec 2013 12:22:26 Todd wrote: On Dec 12, 2013 6:36 PM, Vishesh Handa m...@vhanda.in wrote: i’ll say it again here so that it is at least on record: i really disagree with renaming Nepomuk. call it Nepomuk 2 or whatever, but tossing aside name recognition and years of messaging is doing the promo teams a massive disservice. i hope that Baloo remains a technology name well hidden from both users and developers. It will remain hidden. I am a bit confused by this. You say it will remain hidden, but the emails I am seeing are calling for the outright removal of Nepomuk api calls and replacing them with baloo API calls. This does not seen very hidden from developers. I meant that it will remain hidden to the users. Not developers. Further, you talk about disabling Nepomuk in system settings. This does not seem very hidden from users. So, although I cannot speak for him, I am not sure Aaron's branding concerns are being addressed. Now if this was keeping the Nepomuk namespace and billing baloo as a replacement for virtuoso, then I could see this as being hidden, even with substantial changes in how the APIs actually work. But not when both APIs and user settings are being renamed. The User settings are still called Desktop Search. In fact the KCM is a near duplicate of the Nepomuk one. The Nepomuk API was heavily based around RDF. Moving away from RDF meant redesigning the APIs. If any news site catches wind of this, I don't see how they could present it as anything other than an outright abandonment of Nepomuk, and once that view gets spread around the web no amount of branding later will change it. -- Vishesh Handa
Re: Nepomuk in 4.13 and beyond
On Saturday 14 Dec 2013 21:26:35 Ingo Klöcker wrote: Hmm, I would love to tag my email (using filters) just like Google Mail does so that I can stop filtering my email into folders and I can start using tag folders. This would result in hundreds of thousands of relations tag/email, wouldn't it? We talked about this during the PIM Sprint and decided that the best way to store tags for PIM data would be in Akonadi. That way the tags could also be saved on the corresponding backend (IMAP, Kolab, etc) and they would be synchronized. Additionally, this would also be compatible would other popular clients such as Thunderbird [1][2] The TagRelation was a proof of concept of global tagging which I would like to remove. We're going to be discussing this on Monday after the Plasma Hangout. -- Vishesh Handa [1] http://kb.mozillazine.org/Tags [2] https://wiki.mozilla.org/Thunderbird2:Tags signature.asc Description: This is a digitally signed message part.
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 21:23:51 Aaron J. Seigo wrote: On Thursday, December 12, 2013 20:10:27 Vishesh Handa wrote: On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote: If we all decide to store stuff in sqlite, then it doesn't matter if they are separate database files or the same one. I might be missing a few things here, but asking questions is the road to enlightenment :) - There is no way to query across different stores, which was the main appeal of nepomuk? (I concluded this from the last mail) There isn't one. Not right now. I'm open to ideas on how to do something like if it is required. I'm slightly skeptical if it actually is required. for activities it’s pretty much a requirement: we have an activity and we want to know all resources (files, contacts, bookmarks, applications, windows ..) associated with it. so for activities we’ll either end up querying each store separately or Baloo will need to provide a way to query multiple stores. for the Plasma Active shell as it currently is, single-store querying might be workable as we tend to keep most of the different resources separated in the UI (though that’s one thing i want to change in future releases, so you can group a set of bookmarks with a given file, e.g.) I'm slightly confused. Please correct me if I haven't understood the problem correctly - You have an activity and you have a number of different resources related to that activity. The resource can be a file/contact/application/bookmark/anything. In order to store this, you could just store a mapping between activity id and resource id. Almost identical to what we have for tags. If this was stored in sql. Fetching everything related to a query would be - select * from activityRelation where activityId = 'identifier'; Then, when displaying each of these resources, you would need to query the individual stores they are in. For Contact and Emails, this would be Akonadi. For files, there is a FileFetchJob, etc. it would be a big problem if the tags are per-store as well; we need cross- store tags (though from glancing at the API tonight it looks like that is already there?) Yes. But I'm having second thoughts about this. this may be a question of API, of course. with different stores, collation will need to happen somewhere. should it happen on the client side or the server side is, i suppose, the big question. i would suggest server side for a simple reason: if multiple stores all share the same physical storage system, it would be really nice to be able to optimize queries to hit that storage system as little as possible. example: Stores: S0, S1, S2 S0 - xapian S1 - xapian S2 - mysql when fetching items from S0 and S1 that match tag T0, it would be very nice if the backends could cooperate to merge their queries into one so that one xapian query is done rather than 2 with post-query collation of the results. for obvious reasons this can only be done in the server where the stores can cooperate. a concrete use case: S0 = files S1 = bookmarks S2 = applications application = Plasma Active shell if adding stores is easy enough, i expect we’ll end up with stores for things like geolocation, so this could balloon further. - When querying, how do I get the properties of the results? You don't. You just get the identifier and some text. You can do a subsequent fetch job to get additional data. more roundtrips doesn’t sound great for performance. if a result set has a 1000 returned items and you then want to get properties on them (e.g. for listing and sorting) then one needs to either send all 1000 UIDs back for further processing or in a worst case scenario 1000 individual requests. this will be an issue for several things in Plasma Active, such as the file manager. unlike Dolphin which just shows metadata for a given file, the Active Files app relies on Nepomuk rather than the filesystem for these things and allows filtering by ratings, tags, etc. - We talked about asynchronous querying. Is it going to happen? There is a QueryRunnable class which can be used to run queries in another thread. Most backends, do not seem to allow asynchronous queries, so there wasn't a way to run queries asynchronously by default. those backends could be run in a thread? iow, put the async/threading as a first class feature that the backends must implement. even if it means having a thread for execution in the background and queueing requests. making every user handle the threading sounds like we’ll have lots of code that doesn’t ;) Perhaps. There is always a tradeofff between keeping backend implementations simple, and having complex library code. From my POV, it would be much nicer if you forced a single db (as an actual store, not as a cache like nepomuk is for akonadi) on the people, with the option to have a few things runtime
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 23:33:50 Ivan Čukić wrote: for the Plasma Active shell as it currently is, single-store querying might be workable as we tend to keep most of the different resources separated in the UI (though that’s one thing i want to change in future releases, so you can group a set of bookmarks with a given file, e.g.) Piggy-backing on Aaron's sub-thread. Here's a simpler, yet funnier example: I want all files tagged as 'Dolphin' from 'KDE development' activity. Tags for files are located in one store. Things linked to an activity are in another store. If I got it right, I'd have to: 1 - get a list of things tagged with 'Dolphin' 2 - get a list of things linked to 'KDE development' activity Intersect them. If both are sqlite, then it's one query - select fid from tagRelation, activityRelation where aid = 'activityId' and tid = 'TagIdentifier'; http://www.sqlite.org/lang_attach.html This will also work if tags are in xapian and activities in something else since xapian provides ways to filter the query when it is running - http://xapian.org/docs/postingsource.html So, we need to do this manually, in-memory, loading potentially hundreds of results in order to return a dozen? While the database would do that in an optimized way? I do get the problem of some clients desiring sql, and some not (xapian or whatever else). We would need a way to bridge those anyhow, so why not bridge them in a common place (baloo) instead of relying on each client to implement it by themselves. I'm glad we're on the same page. If you take a look at baloo/src/core/query.h there is an addRelation function which would let you do stuff like - Query q; q.setType(File); q.addRelation(TagRelation(Tag(Spiderman)); q.addRelation(ActivityRelation(someActivity)); it = q.exec(); This isn't currently implemented, but that was the general idea. Returning on one-db-to-rule-them-all-but-not-exactly :) Baloo could provide the client a choice of the backend database. Not in the sense of mysql vs sqlite vs postgresql, but rather of a db type - choose SQL, choose whatever-designation-xapian-has, (ignored: JSON, KeyVals, RDF :) etc.) This way, more complex queries that are limited to stores based on a specific db type would be super-fast, while others would be slower, but still faster than manual implementations. I agree. -- Vishesh Handa
Re: Nepomuk in 4.13 and beyond
On Friday 13 Dec 2013 15:10:32 Shantanu Tushar Jha wrote: Hi Vishesh, While we're doing a better Nepomuk, something that I'll personally love improved is real-time[1] resource updates. We disabled resource watcher in PMC a long time back because it used to slow down things a *lot*. I'd envision something along the lines of signals which would notify the resource IDs (or equivalent) that have changed. While the bare minimum would be creation/deletion, notifications about changes to metadata will rock. Yes. Better monitoring is something we desperately need. Now that we have different stores for each type of data, this will be a lot easier to implement. I still have to work on a monitoring API for Files. There is one already in place for Tags. -- Vishesh Handa
Nepomuk in 4.13 and beyond
Hey everyone During the KDE 4.11 cycle Nepomuk reached a maturity level that we were happy with, it is reasonably fast, stable, and unless used together with Akonadi it is no longer the CPU consumer it was before. We reached this state after years of analyzing what was wrong and what could be improved to the point where we no longer think any more improvement is possible only by modifying our code. The next place where we could seek improvement was the RDF storage. We have been using Virtuoso for about 4 years and it's been a game changer for us performing way faster than any other of the alternatives we ever used before and more efficiently, but as many of you know (and others suffer) it is not a RDF storage designed for the desktop and it will never be. Since nothing better than Virtuoso exists for our use-case, we started to implement our own RDF storage mechanism (codenamed Vishuoso). At some point during that progress we took a step back and re-analyzed the problems of the workspace and the current implementation. The problems are - - Resource Description Framework (RDF) The biggest problem with RDF is that it raises the knowledge needed to contribute to a point where most developers decide to to skip it. After all these years only a handful of brave developers have worked with it and the experience hasn't been good. Then we need something easier to use so we can see a more broad adoption. Additionally, RDF is a very flexible way to store data, it is however not the most efficient way. Data is generally completely normalized even though it is quite often not required. Eg - One doesn't need to store music file artists as a separate contact. This is great, from a theoretical point of view, but it is not very useful in practice. - RDF Storage There is no existing RDF storage designed to work in a Desktop. Virtuoso is great but it quickly uses hundreds of megabytes of ram and it has its own share of problems. The other alternative is tracker, but they lack certain features required in Nepomuk. - Data duplication Nepomuk has been used as both a search store and a data store. This results in massive data duplication and synchronization problems. In the case of Akonadi, emails are stored in Akonadi and are then duplicated in virtuoso, and are then duplicated in virtuoso's index. Every time data is changed in Akonadi it has to be updated in Nepomuk and vice-versa. This results in a process being responsible just for synchronizing the two stores. - API Duplication With the data residing in both Nepomuk and other stores (Akonadi/Files/etc), it isn't always clear which store it should be accessed from. This essentially results in duplication of APIs. Eg - Using KABC vs accessing contacts from Nepomuk. These problems would still exist even if we had the fastest and most efficient RDF storage in the world. At this point it was clear to us that the future was not going to be RDF. The next thing we did was to analyze our actual needs based on the last 5 years of Nepomuk. Our needs are - * Full text index for searching * Data store for simple objects such as tags / ratings / activities / etc * Relations - Forming relations between different objects. Eg - This file is related to this activity or person. Each of these problems is independently solvable without RDF. About 2 months ago we started to draft Baloo [1], a metadata solution that will cover the bare necessities of each use case we have. I'd like to avoid getting into the technical details of the implementation in this thread. Another thread can be started about its different aspects once you've read the basic ideas behind Baloo [2] Current Plans - After a month of designing the solution and a month of implementing it, Baloo is working way better than Nepomuk does. So, I'd like to switch to Baloo by default in 4.13, while keeping Nepomuk in maintenance mode for more conservative distributions. This is not a completely new project as large parts of Baloo code are derived from Nepomuk and therefore comes with years of testing and real world use. Baloo was also discussed in PIM Sprint and the PIM developers are happy to completely drop Nepomuk support for 4.13 and move to Baloo. Similarly, the telepathy developers are also working on moving KPeople away from Nepomuk. Migration - There will be an automated migration mechanism for migrating tags, ratings and comments from Nepomuk to Baloo. Trying it out? --- Developers are welcome to try out Baloo and have a look at the current source code. It's a still a work in progress, but we strongly feel that it is a step in the right direction. I'd recommend using Milou [3] for searching. -- Vishesh Handa [1] https://projects.kde.org/projects/playground/base/baloo [2] http://techbase.kde.org/Projects/Baloo [3] https://projects.kde.org/projects/playground/base/milou
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 12:34:40 Ivan Čukić wrote: Aloha, - Resource Description Framework (RDF) The biggest problem with RDF is that it raises the knowledge needed to I'm not sure this was *the* problem with nepomuk adoption, but lets ignore that for a moment :) So, nepomuk was based on rdf and sparql. Essentially, a simple and standardized yet really slow (and overly academic) technology that (in our case) introduced quite a few issues, as you already stated. What is a replacement for sparql in baloo? (the wiki page is quite underwhelming) Things here seem to be quite separated. Are the different 'stores' at least sharing a same instance of a database? (aka, are akonadi, and other stores going to share a single instance of **sql) If we all decide to store stuff in sqlite, then it doesn't matter if they are separate database files or the same one. Currently, for files, I do not use a sql store except for mapping the file url to a unique identifier. How are the following things going to be implemented (some use-cases that come to mind): - telepathy and akonadi contacts (kpeople implementation) KPeople currently use their own sqlite db to map akonadi and telepathy contacts into people. At some point an API for exposing these details will need to be provided. - linking a contact (kpeople vs akonadi) to an activity I'm hoping you'll have something along the lines of an Activity relation which can be used to map any id with an activity. How you store it is up to you. - linking a file to an activity Same as contacts. You map an activity id with a file identifier. - linking an application to an activity I haven't thought about applications, but if you have a unique identifier for an application, it should be fairly straightforward. - getting emails of contacts that are linked to an activity 1. Fetch the contacts related to that activity 2. Do a query on the Email Store with a from/to/cc/bcc with those contacts - getting emails with attachments of contacts that are linked to an activity 1. Same 2. Do a query on the Email Store with a from/to/cc/bcc with those contacts, but set the attachment flag to true. This would arguable be inferior to have everything in one database where the database does the whole query for you. However, if the need arises we can merge databases are required. Additionally, RDF is a very flexible way to store data, it is however not the most efficient way. Data is generally completely normalized even though Agreed. RDF stores are usually slow because they focus on flexibility as a most common use-case which it is not. you've read the basic ideas behind Baloo [2] As I said, the basic ideas are overly basic when you come from outside world and don't know what is written between the lines. :) Ch! -- Vishesh Handa
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 13:24:04 Aaron J. Seigo wrote: hi ... just replying to k-c-d because i loath massively-cross-posted email discussions. On Thursday, December 12, 2013 11:46:53 Vishesh Handa wrote: Each of these problems is independently solvable without RDF. ah, how wonderful. what you describe is amazingly similar to the system Wheeler and I came up with during the very first Akademy. if you’re ever interested in what ever became of that, remind me over a coffee/beer sometime and i’ll put on my old-man pants and recount the ol’ days. ;) Sure. Plasma sprint. After a month of designing the solution and a month of implementing it, Baloo is working way better than Nepomuk does. So, I'd like to switch to Baloo by default in 4.13, while keeping Nepomuk in maintenance mode for more conservative distributions. how does one switch to Baloo in a sane fashion? (so we can help test and perhaps even work on integration elsewhere. i don’t care about migration ..)) Disable Nepomuk (System settings) and install Baloo. It should startup on boot, otherwise you can run the baloo_file process. Most of the PIM side is already integrated, but the patches still have to be pushed. (I'll push them into a clone) I've started working on porting Dolphin, but I need to talk with Frank. What exactly do you want to integrate? what is the Baloo equivalent of the Nepomuk API currently in kdelibs? (i’ve looked in the ballo repo, it isn’t clear at first glance) There isn't a clear Resource API any more. There is a nice query API - take a look at baloo/src/core/query.h / term.h. There are some examples in the autotests directory. This is not a completely new project as large parts of Baloo code are derived from Nepomuk and therefore comes with years of testing and real world use. i’ll say it again here so that it is at least on record: i really disagree with renaming Nepomuk. call it Nepomuk 2 or whatever, but tossing aside name recognition and years of messaging is doing the promo teams a massive disservice. i hope that Baloo remains a technology name well hidden from both users and developers. It will remain hidden. Migration - There will be an automated migration mechanism for migrating tags, ratings and comments from Nepomuk to Baloo. cool Another thread can be started about its different aspects once you've read the basic ideas behind Baloo i’ve done so and even looked briefly at the code. where do you want the discussion to occur? i have some technical questions already :) We may as well continue here. -- Vishesh Handa
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 19:08:23 Aaron J. Seigo wrote: On Thursday, December 12, 2013 18:28:24 you wrote: What exactly do you want to integrate? Plasma Active things. Could you please enumerate what all that involves? From what I know there is - 1. Metadata model for running queries 2. Timeline based stuff - again, queries 3. Showing File metadata - There is a File class and a FileFetchJob 4. File ratings/comments - There is no API right now as I haven't decided how to store them. Simeon (an awesome Nepomuk contributor) had the idea of storing them as extended attributes. I still need to investigate more, but it seems like a good idea. 5. Tags - read below. what is the Baloo equivalent of the Nepomuk API currently in kdelibs? (i’ve looked in the ballo repo, it isn’t clear at first glance) There isn't a clear Resource API any more. There is a nice query API - take a look at baloo/src/core/query.h / term.h. There are some examples in the autotests directory. ok; will there be a Resource style API in future, or will it just be queries from here on out? What would you like to use the Resource class for? There is a replacement for files, but I have nothing planned for anything else. i’ve done so and even looked briefly at the code. where do you want the discussion to occur? i have some technical questions already :) We may as well continue here. okie dokie.. my first big question is: how are tags related to data in different stores? The initial idea was to have a different TagStore which stores information about tags such as their name, color, icon, etc. Additionally there would be a TagRelation class which connects anything with a tag. Have a look at baloo/src/tags/. The code has a large number of unit tests. That being said, during the PIM Sprint we established that we want server side tags w.r.t emails and other PIM data. This means two different ways of accessing tags. I was thinking of throwing away the concept of tagging anything, and only allow tagging of files. This way we could store the tag metadata in the extended attributes for a file. From what I hear, Mac also stores tags as extended attributes. -- Vishesh Handa
Re: Nepomuk in 4.13 and beyond
On Thursday 12 Dec 2013 19:40:11 Ivan Čukić wrote: If we all decide to store stuff in sqlite, then it doesn't matter if they are separate database files or the same one. I might be missing a few things here, but asking questions is the road to enlightenment :) - There is no way to query across different stores, which was the main appeal of nepomuk? (I concluded this from the last mail) There isn't one. Not right now. I'm open to ideas on how to do something like if it is required. I'm slightly skeptical if it actually is required. - When querying, how do I get the properties of the results? You don't. You just get the identifier and some text. You can do a subsequent fetch job to get additional data. This is however just the generic Query API, if required we can design better APIs for something you have in mind. I have some specialized APIs for querying PIM data which are more useful in certain cases. When asking for the attachments sent by Alice, I don't care only about the id, title and the icon of the result. I'd like to get the mimetype, size etc. (for example, to group the results), or for further processing if I have no desire to show the results directly to the user. Can I retrieve those with baloo api? Do I need to make separate queries for those? Attachments are a strange corner case, in Akonadi, where it isn't really a file since it does not have a url, and is not dereference-able. For normal files, you currently just get the url. The Result class looks like it was tailored only for displaying the results to the user - KRunner style (design of it all looks quite similar to KRunner to be honest). It was designed for Runners, Dolphin, and Email Search. It wasn't designed to be a Nepomuk Query API replacement. - We talked about asynchronous querying. Is it going to happen? There is a QueryRunnable class which can be used to run queries in another thread. Most backends, do not seem to allow asynchronous queries, so there wasn't a way to run queries asynchronously by default. I see a lot of KJobs for altering stuff, but Query and ResultIterator do not look async. Just imagine a store that wants to query currently open windows (via dbus connection to kwin), or currently open documents for an activity (requires connection to both kamd and kwin). It can not be done sanely in a synchronous way. One of the main things in libkactivities was to make everything be totally async. I'm open to suggestions on how to implement queries in an async manner. - Database integration When we talked about the nepomuk successor at Akademy, one of the main benefits I saw at the time was the possibility to integrate all dbs into one (and shut up all the people who complain we like dbs too much :) ). Baloo seems to go out of its way to accommodate the fact that everybody is using different things (be it mysql, embedded mysql, sqlite, plain text etc.). From my POV, it would be much nicer if you forced a single db (as an actual store, not as a cache like nepomuk is for akonadi) on the people, with the option to have a few things runtime defined. It would ease the development and would allow more fun queries which would be optimized unlike the manual client-side joining of different query results. But what if one doesn't use SQL for storing data? IMO Xapian is much better suited that sqlite's FTS support (or mysql). I agree with you on the fun query bit, but I'm skeptical if those fun queries are genuinely required. How about we list down the use cases and then see? When planning Baloo, I've mostly taken a look at PIM, Dolphin, KRunner (and Milou), PMC, and KPeople. Perhaps something was missed? Cheerio, Ivan. -- Vishesh Handa
Re: Review Request 113190: KPropertiesDialog: Do not show the KFileMetaDataWidget
On Oct. 11, 2013, 6:14 a.m., David Faure wrote: Which branch is this for? Master? Yes this is for master. We'll still be having a 4.12 release of kdelibs, right? - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113190/#review41541 --- On Oct. 10, 2013, 10:45 a.m., Vishesh Handa wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113190/ --- (Updated Oct. 10, 2013, 10:45 a.m.) Review request for kdelibs and David Faure. Bugs: 324879 http://bugs.kde.org/show_bug.cgi?id=324879 Repository: kdelibs Description --- KPropertiesDialog: Do not show the KFileMetaDataWidget The KFileMetaDataWidget uses Nepomuk1 which is deprecated and is buggy. It would be better for people to use the Nepomuk2::FileMetaDataWidget. This mostly only affect Dolphin where users can tag files via the Information Panel and via File-Properties. This removes the widget in the File-Properties BUG: 324879 Diffs - kio/kfile/kpropertiesdialog.cpp b4cd8ee Diff: http://git.reviewboard.kde.org/r/113190/diff/ Testing --- The Information tag is no longer shown in the FileProperties dialog Thanks, Vishesh Handa
Re: Review Request 113190: KPropertiesDialog: Do not show the KFileMetaDataWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113190/ --- (Updated Oct. 14, 2013, 10:25 a.m.) Review request for kdelibs and David Faure. Changes --- Added 'master' branch in the review branch field. Bugs: 324879 http://bugs.kde.org/show_bug.cgi?id=324879 Repository: kdelibs Description --- KPropertiesDialog: Do not show the KFileMetaDataWidget The KFileMetaDataWidget uses Nepomuk1 which is deprecated and is buggy. It would be better for people to use the Nepomuk2::FileMetaDataWidget. This mostly only affect Dolphin where users can tag files via the Information Panel and via File-Properties. This removes the widget in the File-Properties BUG: 324879 Diffs - kio/kfile/kpropertiesdialog.cpp b4cd8ee Diff: http://git.reviewboard.kde.org/r/113190/diff/ Testing --- The Information tag is no longer shown in the FileProperties dialog Thanks, Vishesh Handa
Re: Review Request 113190: KPropertiesDialog: Do not show the KFileMetaDataWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113190/ --- (Updated Oct. 14, 2013, 4:16 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs and David Faure. Bugs: 324879 http://bugs.kde.org/show_bug.cgi?id=324879 Repository: kdelibs Description --- KPropertiesDialog: Do not show the KFileMetaDataWidget The KFileMetaDataWidget uses Nepomuk1 which is deprecated and is buggy. It would be better for people to use the Nepomuk2::FileMetaDataWidget. This mostly only affect Dolphin where users can tag files via the Information Panel and via File-Properties. This removes the widget in the File-Properties BUG: 324879 Diffs - kio/kfile/kpropertiesdialog.cpp b4cd8ee Diff: http://git.reviewboard.kde.org/r/113190/diff/ Testing --- The Information tag is no longer shown in the FileProperties dialog Thanks, Vishesh Handa
Re: Review Request 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- (Updated Oct. 14, 2013, 4:16 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa
Review Request 113190: KPropertiesDialog: Do not show the KFileMetaDataWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113190/ --- Review request for kdelibs and David Faure. Bugs: 324879 http://bugs.kde.org/show_bug.cgi?id=324879 Repository: kdelibs Description --- KPropertiesDialog: Do not show the KFileMetaDataWidget The KFileMetaDataWidget uses Nepomuk1 which is deprecated and is buggy. It would be better for people to use the Nepomuk2::FileMetaDataWidget. This mostly only affect Dolphin where users can tag files via the Information Panel and via File-Properties. This removes the widget in the File-Properties BUG: 324879 Diffs - kio/kfile/kpropertiesdialog.cpp b4cd8ee Diff: http://git.reviewboard.kde.org/r/113190/diff/ Testing --- The Information tag is no longer shown in the FileProperties dialog Thanks, Vishesh Handa
Review Request 113153: Deprecate KFileMetaDataWidget and KFileMetaDataConfigurationWidget
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113153/ --- Review request for KDE Frameworks and kdelibs. Repository: kdelibs Description --- They will no longer exist in KF5, and everyone should be using the Nepomuk widgets instead. Diffs - kio/kfile/kfilemetadataconfigurationwidget.h 6be2a0d kio/kfile/kfilemetadatawidget.h 50ddce9 Diff: http://git.reviewboard.kde.org/r/113153/diff/ Testing --- Thanks, Vishesh Handa
Re: Review Request 112852: Proposed patch to enable compilation of nepomuk-core on Mac
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/#review40585 --- I'm okay with this, but I'm not well versed with cmake magic. If no one else objects, feel free to push this. It can always be reverted. - Vishesh Handa On Sept. 21, 2013, 7:53 a.m., Nicolas Pavillon wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112852/ --- (Updated Sept. 21, 2013, 7:53 a.m.) Review request for kdelibs and Nepomuk. Description --- Patch to solve the bug reported at https://bugs.kde.org/show_bug.cgi?id=325058. This addresses bug https://bugs.kde.org/show_bug.cgi?id=325058. http://bugs.kde.org/show_bug.cgi?id=https://bugs.kde.org/show_bug.cgi?id=325058 Diffs - tools/nepomukctl/main.cpp 9d350ea Diff: http://git.reviewboard.kde.org/r/112852/diff/ Testing --- Applied the patch on several OS X platforms to ensure that compilation does not crash. See https://trac.macports.org/ticket/40498 for details. Thanks, Nicolas Pavillon
Re: Releases in 3 months
From my point of view, 3 month releases are going to actually increase quality. At least in Nepomuk. The Nepomuk developers (me included) have often merged feature branches right before the feature freeze even if the branch has some problems. No one wants to wait 8 months (2 months for the current release, and 6 months for the next) for the users to get the feature they are working quite hard on. The end result is that certain things aren't always polished, and the user experience suffers. With 3 month releases one can actually take a decision and delay the feature by about 4-5 months, which is still reasonable. 8 months is just too long to wait. Additionally, with these 3 month releases I am more inclined to release improvements for Nepomuk in 4.12. If 4.12 is supposed to be released in January, I won't be working on any new features. I'll start focusing on KF5, and the role Nepomuk will play over there. Effectively making 4.11 the last release for Nepomuk as well. On Mon, Jul 8, 2013 at 6:34 PM, Àlex Fiestas afies...@kde.org wrote: Now that kde-workspace and kdelibs are going to be frozen (which in theory means less work for everybody) I'd like to propose a new release schedule to be applied starting with 4.12. Basically the idea is to cut testing time and compensate it by keeping master always in a releaseable state, now that two major components are frozen it looks like it is a good time to get used to it. You can read all the proposal in: http://community.kde.org/KDE_Core/ReleasesProposal Before sending this email I have checked with distro people, i18n people, other developers and almost all of them seemed to either like or be neutral about it (only one exception :p) so I hope that the proposal is not a complete disaster. As its name indicates, it is a proposal, so please be constructive in the feedback, we can change as many things as we need. Finally, I have scheduled a Bof at Akademy, would be nice to have all the feedback from the community that is not able to come before it happens: http://community.kde.org/Akademy/2013/Wednesday#Room_A2_-_17_July Cheers ! -- Vishesh Handa
Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 4:13 PM, Scott Kitterman k...@kitterman.com wrote: These all have to be test compiled, checked for new or missing files, checked for files that have moved between packages, checked for license/copyright updates, etc. I guess you have all this mostly automagically done? Some yes, some no. The copyright/licensing stuff is the hardest and it's very manual. It's work that has to be done to ensure we are legally distributing the packages, so there's no way around it. Could you please elaborate why the licensing stuff cannot be automatically done? Most licenses follow a similar template. In fact most developers just copy paste the license (as they should). I can imagine writing a simple script the extract the copyright holder's name and type of license from any file. Maybe it would only work for 90% of the cases, but it should still work. And for that remaining 10%, you can always ask the developer to use a standard version of the license, thereby decreasing your work in the future. -- Vishesh Handa
Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 5:58 PM, Scott Kitterman k...@kitterman.com wrote: There I'd a licensecheck script that does this. It helps, but the results have to be checked and properly documented and so thete is still substantial manual work required. KDE packages are generally better about consistently documenting copyright and licensing, but we still find bugs and it's still a lot of work. Can we as KDE developers do something to reduce this work load? We could create git hooks which reject patches with incompatible licesnses? Or something like that? Once the script has extracted the infromation, do you really need to check it? Proper documentation can be automatically generated. (Unless I'm missing something) My overall point is that this problem seems more of a technical one than one related to release schedules. It should be fixed as it would considerably reduce the work distributions have to do. -- Vishesh Handa
Re: openSUSE packagers' take on the 3 month release cycle
On Tue, Jul 9, 2013 at 6:08 PM, Harald Sitter sit...@kde.org wrote: there would not be any problem. But reality diverges :( I'm all for fixing this in at least KDE SC. That way if/when we have shorter releases you can have some kind of guarantee that you will not encounter strange behaviours like the one you described. Also, in my head, the script would detect something like this and inform you that it does not know how to deal with such a text. You can then file a bug report, email the developer or whatever, and it will be fixed. We can even mark such bugs as blockers (maybe?) so that they have to be fixed before the release. -- Vishesh Handa
NepomukCore - Do not merge KDE/4.10 into master
Hey everyone As you might have heard there was a fiasco in the nepomuk-core repository where the 'master' branch was accidentally merged into KDE/4.10. Since then the system admins had to do a hard reset to v4.10.2 and I had to manually cherry-pick a lot of the commits. I do not want anyone to merge KDE/4.10 into master. It will lead will a number of duplicate commits, and considering we already have a LOT of duplicates I do not want any more. Thanks -- Vishesh Handa
Re: Review Request 109675: Make sure that the KDE prefix comes first in XDG_DATA_DIRS
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109675/#review29850 --- Seems like a good idea to me. I cannot have a Ship it as I'm not familiar with the code. Btw, I just checked and I have a `prepend XDG_DATA_DIRS $KDEDIR/share` in my KDE environment variables, that is probably why I never encountered this. - Vishesh Handa On March 24, 2013, 4:31 p.m., Andreas Hartmetz wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109675/ --- (Updated March 24, 2013, 4:31 p.m.) Review request for kdelibs and Vishesh Handa. Description --- Planned commit message: Make sure that the KDE prefix comes first in XDG_DATA_DIRS. I tracked down a Nepomuk problem to this. Nepomuk file indexing didn't work because the ontologies were too old. Nepomuk loaded ontologies from /usr/share instead of my KDE prefix /opt/kde4/share, because /opt/kde4 was the very last entry in the respective search list in KStandardDirs. The first entries in that search list all came from XDG_DATA_DIRS, which in my case (Kubuntu) is set by the X session initialization scripts. That is before startkde runs, so startkde never touched XDG_DATA_DIRS. But it should, and now it does. Diffs - startkde.cmake 8361fe0 Diff: http://git.reviewboard.kde.org/r/109675/diff/ Testing --- Thanks, Andreas Hartmetz
Re: KDEReview: Nepomuk-Controller QML
On Sat, Mar 23, 2013 at 8:12 PM, Jörg Ehrichs joerg.ehri...@gmx.de wrote: So after a first introduction in plasma, I like to get this thing into SC. The Nepomuk-Controller aims to replace the current system tray Nepomuk applet. This one allows to suspend/resume and show information for all the indexers, thus this gives any user a small hint what happens in the background and allow them to suspend it, if they need to. For the review I have pushed the branch nepomukcontroller-qml into kde-workspace. You can find the important parts at plasma/generic/dataengines/nepomuk plasma/generic/applet/nepomuk-controller The dataengine as well as the applet is only installed if Nepomuk-Core/Soprano is found as build dependency. This would deprecate: kde-runtime/nepomuk/controller/ Deprecate or remove? Cause I would like to remove it. and need current nepomuk-core master For an easy to install version there is also: http://quickgit.kde.org/?p=scratch/jehrichs/nepomukcontroller-qml.git Some Pictures: http://wstaw.org/m/2013/03/20/nepomukcontroller-qml1.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml2.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml3.jpg http://wstaw.org/m/2013/03/20/nepomukcontroller-qml4.jpg Any help/comments are welcome. Since my first mail on the plasma devel list, the dbus calls are asynchrone now, the FileWatch service is not shown on default, but can be enabled if the user wants, and the licence should be fine now. Kind Regards Joerg -- Vishesh Handa
Re: Review Request 109538: port KFileMetaDataReader to QProcess
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109538/#review29377 --- But why? KFileMetadataReader and the other KFileMetadataStuff should just be marked as deprecated. Why are we porting them? We already have better alternatives in the nepomuk-widgets repository. - Vishesh Handa On March 17, 2013, 1:26 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109538/ --- (Updated March 17, 2013, 1:26 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Vishesh Handa. Description --- KFileMetaDataReader currently uses KProcess, this ports it to use QProcess instead. Diffs - kio/kfile/kfilemetadatareader.cpp 88cadaa Diff: http://git.reviewboard.kde.org/r/109538/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request 109538: port KFileMetaDataReader to QProcess
On March 17, 2013, 2:05 p.m., Vishesh Handa wrote: But why? KFileMetadataReader and the other KFileMetadataStuff should just be marked as deprecated. Why are we porting them? We already have better alternatives in the nepomuk-widgets repository. Martin Tobias Holmedahl Sandsmark wrote: Because it was a simple user of KProcess. But if we can just deprecate the whole class (and move it into kde4support, I guess?) that's better. :-) As far as I'm concerned it can be deprecated. We can definitely deprecate KFileMetadataWidget which is the only user of this KFileMetadataReader. Dolphin now uses Nepomuk2::FileMetadataWidget. The only slight problem might be that Dolphin still likes being Nepomuk Optional at compile time. So they still use it. Maybe we should talk to Frank about this? The only other class is KFileMetaInfo, which uses Strigi directly. I still have to write a replacement for that in Nepomuk. @David: I think we talked about this in Berlin. Should we deprecate KFileMetadataWidget? - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109538/#review29377 --- On March 17, 2013, 1:26 p.m., Martin Tobias Holmedahl Sandsmark wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109538/ --- (Updated March 17, 2013, 1:26 p.m.) Review request for KDE Frameworks, kdelibs, David Faure, and Vishesh Handa. Description --- KFileMetaDataReader currently uses KProcess, this ports it to use QProcess instead. Diffs - kio/kfile/kfilemetadatareader.cpp 88cadaa Diff: http://git.reviewboard.kde.org/r/109538/diff/ Testing --- it builds. Thanks, Martin Tobias Holmedahl Sandsmark
Re: Review Request: Make Strigi optional on OS X
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108315/#review25141 --- AFAIK, Strigi is only used if KFileMetaInfo in kdelibs. Removing it will break the following - http://lxr.kde.org/ident?i=KFileMetaInfo The most notable of these is wallpaper handling in Plasma. I'm not sure if it will break - but it won't display the resolution of the images when choosing a wallpaper. You could also possibly do the same in kde-runtime. There seems to be a trash analyzer for strigi, but that hasn't been installed since 2007 - commit f3578b6c8c27ff1808cb464e5a95fc803e6c84b0 Author: Laurent Montel mon...@kde.org Date: Fri Apr 20 10:06:23 2007 + Don't install it for the moment need to fix it svn path=/trunk/KDE/kdebase/runtime/; revision=656108 I wonder why it is still being compiled. If it is not required, then it can be thrown away and strigi can be removed as a dependency from kde-runtime completely (Linux, Mac and Windows) - Vishesh Handa On Jan. 10, 2013, 3:49 a.m., Yue Liu wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/108315/ --- (Updated Jan. 10, 2013, 3:49 a.m.) Review request for kdelibs. Description --- Some kde apps can work without strigi on OS X, this patch is for reduce dependencies when packaging those apps, but i don't know whether it can be optional for official kdelibs on OS X. So I put it here, please give some comments. Diffs - CMakeLists.txt 5df26e5 kde3support/CMakeLists.txt 2e91b73 kdewidgets/CMakeLists.txt 5153601 kfile/CMakeLists.txt ceae140 khtml/CMakeLists.txt 99034cc kio/kio/kfilemetainfo.h 6920ffe kioslave/metainfo/CMakeLists.txt cbf2d86 kparts/CMakeLists.txt 2eab2e8 Diff: http://git.reviewboard.kde.org/r/108315/diff/ Testing --- Compiles. Some apps works. Thanks, Yue Liu
Re: Review Request: Initialize datetime of tags in tags:// protocol
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107910/#review24245 --- Ship it! I'm sorry. I seen to have not seen this. Please add the nepomuk group from next time. - Vishesh Handa On Dec. 25, 2012, 5:35 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107910/ --- (Updated Dec. 25, 2012, 5:35 p.m.) Review request for KDE Runtime and Vishesh Handa. Description --- Tags listed in tag:// protocol show created/modified date as 7.2.2106 06:28 (which is apparently timestamp of UINT_MAX). I think showing current datetime would be better :) Diffs - nepomuk/kioslaves/tags/kio_tags.cpp a6f4632 Diff: http://git.reviewboard.kde.org/r/107910/diff/ Testing --- Thanks, Dan Vrátil
Re: Review Request: Initialize datetime of tags in tags:// protocol
On Dec. 30, 2012, 1:23 p.m., Vishesh Handa wrote: I'm sorry. I seen to have not seen this. Please add the nepomuk group from next time. *seem to have not seen this - Vishesh --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107910/#review24245 --- On Dec. 25, 2012, 5:35 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/107910/ --- (Updated Dec. 25, 2012, 5:35 p.m.) Review request for KDE Runtime and Vishesh Handa. Description --- Tags listed in tag:// protocol show created/modified date as 7.2.2106 06:28 (which is apparently timestamp of UINT_MAX). I think showing current datetime would be better :) Diffs - nepomuk/kioslaves/tags/kio_tags.cpp a6f4632 Diff: http://git.reviewboard.kde.org/r/107910/diff/ Testing --- Thanks, Dan Vrátil
Python bindings for nepomuk-core
Hey everyone The nepomuk-core [1] package was released with KDE SC 4.9. It contains a ton of new APIs for Nepomuk, along with the apis in kdelibs/nepomuk, under a new Nepomuk2 namespace. Luca Beltrame had put me in touch with Simon about this in July and August, but no progress has been made. I would really like to have python bindings for nepomuk-core in 4.10. This is important cause kdelibs/nepomuk is going to be marked as deprecated. Do you think something could be done? [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core -- Vishesh Handa
Re: Nepomuk Metadata Extractor moved to KDE Review
Hey Jorg A couple of things 1. You have multiple extractors - One for resources which extract information from the file, and some web-extractors. Considering that Nepomuk now allows easy Qt based extractor plugins, how about we move your code over there? Your poppler based code would be quite useful. Same goes with the ODF. 2. Project Name - If one moves the extractors away, the only part that is left is the web-extractors. Why not rename the project to Nepomuk-WebExtractor or something similar? I know a project by that name already exists, but that can be removed. It's a dead project. 3. I would eventually like this to be a part of the KDE SC release. Web Extractors are something that I have wanted for a very very long time. I'm not sure if we can get this into 4.10, but I'd definitely like it to be a part of 4.11. As to where it should be placed. I agree with Sebastian Kugler, kdelibs is not the place. We had initially planned on splitting kde-runtime/nepomuk into multiple repositories, but we're now waiting for KF5. Do you think this could go under kde-runtime (not in that repo) 4. ResourceWatcher - This is something that I would like done in the future. Not right now. We don't need to be perfectionists. I would ideally like this to be part 3 of the file indexing system we have. Currently part 1 pushes the stat + rdf:type + mimetype. Part 2 indexes the contents of the file ( Your resource extractors go here ), and part 3 could extract information from the web. This way, you would avoid using the ResourceWatcher, and everything would be better integrated. But I'm not sure how we would go about this, so lets stick with the current architecture for now. 5. Auto generated SimpleResource Headers - You've included them in your repo. That was what we originally wanted. We didn't want to repeat the mess that happened with breaking kdepim cause of ontology changes. Does anyone have a problem with having generated headers in the code? One could generate them on the fly, but that would be slow (Jorg says around 10 minutes?) and if something is changed in the ontologies, the classes would change drastically thereby affecting the code. On Wed, Oct 31, 2012 at 3:41 AM, Jörg Ehrichs joerg.ehri...@gmx.de wrote: Hi all, today I've moved my metadata extractor into KDE Review [1]. As kde-libs is frozen till kf5 I like to get this into extragear/base (unless anyone has a better idea where to put this). For those who are unaware what this little program does: This programs is an extension to Nepomuk and is able to find additional metadata for videos/music and documents on the Internet. Based on filename / previous metadata extraction / mimetype one of the existing python plugin based (thanks to KROSS) fetcher are called, to get more information for a file. This can be, title, season, episode, writer, author, cast, cited references and so on. All this data is saved into Nepomuk and can be used with Dolphin / Bangarang to get more information from your files. The program is integrated into the dolpin service menu, can be called as command-line program, runs as a Nepomuk2::Service in the background (can be switched off) and has also adapters to be able to integrate into Konqueror and Chromium. More information on it can be found on my blog [2]. Some more technical description is available via doxygen. Please review the current codebase to help this getting as stable as possible. Thanks in advance, Joerg [1] https://projects.kde.org/projects/kdereview/nepomuk-metadata-extractor [2] http://joerg-weblog.blogspot.de/search/label/Metadata%20Extractor -- Vishesh Handa
