- User Since
- Feb 14 2017, 10:36 AM (95 w, 3 d)
Wed, Nov 21
I believe can do something better here.
I think if we stick to canonical paths everywhere, and resolve symlinks ASAP (but still follow them), that might solve all the problems.
Thu, Nov 15
It seems like you've pushed something related to XML extractor as well
Nov 14 2018
Apart from trivial comment, this looks fine. I've tested it on my setup (with bunch of (e)ps files), and randomly chosen files seems to be indexed nicely. It also reduced the size of the index by almost 50MB, because those are not indexed as plaintext anymore :)
Yet I would also vote for replacing it (eventually) with a full-featured extractor based on libspectre
(I'm not a security specialist in any way, but that CVE doesn't look too harmful, and from my point of view it's not worth to abandon full support of (E)PS because of it)
It's a bad idea to removeRecursively starting from root of the tree (documentid 0).
If user has indexed /home/username folder, there is also an index entry for /home (that's how IdTreeDB works).
However, /home should not be indexed, according to checks (because it's not in includeFolders, while /home/username is)
This will lead to removeRecursively("/home") call, which will wipe index for /home/username as well.
Rebase on master
Oct 30 2018
Yep, fine by me
That's nice! I'll test it a little.
Sorry, I've postponed this one for some time :(
Oct 20 2018
BTW. Is there any reason why i.e. inside PostingDB Baloo stores key -> encoded list of values, instead of using MDB_DUPSORT | MDB_DUPFIXED (which allow to store multiple values for keys)?
Dropped in favor of D16265: [Scheduler] Use flag to track when a runner is going idle, which handles this problem better.
I like it, it's better than D15959: Wait for the extraction process to finish before scheduling.
And it seems to be working, as far as I can see :)
Oct 17 2018
Oct 16 2018
Here is some test data for my (rather simple) setup.
Oct 15 2018
Oct 14 2018
Oct 13 2018
Replaced size() by count(), which is more appropriate here
Oct 12 2018
That's weird. I caught it only once and thought that it is because I trivially forgot the endl. But now I cannot reproduce it anymore.
Seems like it should be fine, since we do emit finished signal, which will write the 'OK' part.
Sorry for the noise.
Woops! startedIndexingFile does not print a newline. I guess I can just add m_out << endl...
Address raised issues
I'm not entirely sure how translating system works, but won't it pop up as 4 identical lines in i.e. Lokalize, causing frustration to our translators?
It would also mean that if we would want to change the message, we would have to do it in 4 different lines.
Oct 9 2018
Does this run at startup? If so, this will erase the entries of files on a removable volume not already mounted.
Whoa, thanks for the notice. Not cool, forgot about it.
Probably need to add some checks in IndexCleaner, about the device.
Oct 8 2018
Hah, looks like you pushed a commit for it last year!
I'm not wedded to symlink support, but if we're not going to do it, we should close the bug with some good reasons.
Looks fine to me. But do we really need to optimize it? I mean, I didn't see it running more than ~20 ms, and with this patch for small queries it runs like ~16 ms. Worst case is when user types something in KRunner, but again, the lag is negligible there.
Maybe we should print also a suggestion to user, something like (maybe rephrase it better)
WARNING: Looks like your index is corrupted. We suggest you to run `balooctl disable && balooctl disable` to wipe it and rebuild from scratch
so they won't have to google what to do (there's still not much can be done in that case)
Oct 7 2018
I never experienced such corruption, though, but sanity check shouldn't hurt.
I would like to comment on that and add my 2 cents:
Oct 6 2018
I've found the relevant bug: https://bugs.kde.org/show_bug.cgi?id=333678
That doesn't looks like it works all the time: sometimes I still have this issue.
Apparently, it still can happen that even when the process is finished, signal is emitted, but the thread is not finished yet.
I can look at these, shouldn't be too hard.
Weird, bug 364858 should be fine as it is - user asks for a way to display files Baloo is currently processing, but that's exactly what monitor does (even without this patch).
Oct 5 2018
Oct 4 2018
[balooctl] Monitor also for state changes
Oct 2 2018
As for LyX it's not just menu closing unexpectedly, but it's just totally unusable: I cannot access menu using the applet at all. That was the main reason I started looking into it.
I've implemented ContactGroup support, so now the plugin seems to be fully functional, so I'm switching to KAddressBook side of the story. Apart from adopting View to work with PersonModel, we also need few other stuff.
- As far as I understood, we want to ship the plugin with akonadi-contacts. Yet if we want to feed an EntityTreeModel from KAddressBook, we need AkonadiDataSource to be accessible from there. That would mean that we need to:
- Export those headers & link KAddressBook to plugin library. Sounds a bit weird to me, those plugins are supposed to be runtime dependencies, and we shouldn't break if those are removed.
- Or we can just ship that plugin with KAddressBook. Which is also a bit weird, since it's a general-purpose plugin, which in principle can be used within any application (if there will be anything that supports KPeople...)
- We can also add another API for PersonPluginManager to feed arguments (QVariantList args) to a plugin (we don't know the dataSourceId before loading it, but we know KPluginLoader::pluginName, which I believe should be akonadi_kpeople_plugin), without having an access to a class itself.
- UI for contacts merging and unmerging (a simple button in context menu / toolbar?)
- Code to merge several KContacts::Addressee into a single one, to feed it to the Contact Details Viewer when user selects a metacontact
- (?) Might be useful to be implemented inside KContacts framework
- (?) In principle, several contacts might have different names / avatars (and other unique fields), and it would be nice if user could specify which one he would like to use for metacontact. For example, KPeople does it basically randomly - first contact that appears in its internal list is returned. Don't really now how to do it the simple way.
- UI for editing a metacontact. I guess we can just ask user which of the subcontacts he wants to modify, and then just show him existing dialog for a single contact.
- An "Edit [...]" item for each subcontact in the context menu?
- A separate dialog that asks user which of subcontacts he would like to modify? (gosh, I hate UIs which show dozens of nested sub-dialogs...)
- A drop-down menu (or any other UI element) inside an already existing Contact Edit Dialog, that allows user to specify the subcontact?
- UI for duplicates suggestions - that's a must-have feature (based on names / phones / emails, maybe something else). There is some UI for it inside KPeople, but I haven't looked into it yet.
Oct 1 2018
Sep 30 2018
Sep 29 2018
Sorry for that! Of course it should be QStringLiteral("ktp://") instead. I've fixed it in master
So far merging works, but occasionally it crashes (didn't find reliable way to reproduce). It also works weirdly when I try to merge two (already) metacontacts.
Interestingly enough, it doesn't crash the testing application, but plasmashell. My guess that it's due to KTp Instant Messanging plasmoid, which interacts with Plasma.
Sep 28 2018
Merge/Unmerge functionality appeared to be fairly simple, it's done via KPeople::mergeContacts(QStringList &uris) and KPeople::unmergeContact(QString uri). It kinda already works (as simple as that), see the repo.
Sorry for long delay, was busy with other stuff...
Sep 21 2018
Can this potentially throw off the order of items or cause items to be removed that got inserted previously (ID clash?)?
As far as I can see, it should not be the case: those two operations should be totally interchangeable.
Both "insert/update" and "remove" actions are based on rootItem.children (which contains new layout of menu). Menu items that are inside it got updated, those who are not - got removed.
Sep 17 2018
Sep 16 2018
I've decided to make a scratch repo and to publish there what is done so far. It includes ported viewer (based on 2014-dated GSoC project), which is a bit broken, but whatever - it still can be used for debugging.
TODO: it would be nice to view all internal data of AbstractContacts there; as well as fancy tree-view with metacontacts & contacts. But that's for the future.