• [Plasma Search KCM] Re-organize the tab and widget layouts.
• Add edit actions.

• [KRunner] Change start of line shortcut to CTRL + S.
• [KRunner] Re-work the shortcut handling to allow modifying the shortcuts.
• Make edit actions configurable.
• Follow standard shortcuts nomenclature.
• Fix clear action.

In D16579#428993, @bruns wrote:

The change, as you pushed it, was never open for review, so there was not even the chance to review.

The change was ack'ed in this review, and this review closed by the commit.

In D16579#428790, @ngraham wrote:

Two reviewers had open "Changes Requested" statuses on this patch when you committed it, and from the latest comments, it's not clear that their concerns were addressed first. Can you explain your thought process regarding why you felt it was appropriate to ignore your reviewers as well as KDE community norms and commit this anyway?

This test fails:

Anyway, most of this special handling of mimetypes goes away with D18826, where TagLib will do the conversion automatically.

I realise that with all the fields referenced here having at least one standard fieldname parsed now that complaining may seem to be flogging a dead horse, but I'd like to re-iterate that identically-purposed fields should not be encouraged. This is at best a specialized re-purposing that really shouldn't be. Maintaining a branch / fork for this is probably appropriate.

• Use the de-facto Album Artist field name for APE tags.

Re-base.

Timezone name expansion, date into the future, and multiple matches:

"Locking" the scheduler is simpler here than identifying that it "has gone idle". "Locking" only happens here for a small number of runnables (two) that can't run concurrently.

• Re-write the file index scheduler. Combine content indexer suspend logic.
• Update the balooctl tool with the changed suspend/resume behaviour.
• Re-order and use IndexerState to prioritize the indexer thread pool.
• Newline and tab fixes.
• Prevent a scheduler race condition.
• Separate runnableStateChanged into two functors.
• Allow the first run indexer to complete before running any other runnables. Prevent the new file and unindexed file runnables from running at the same time.
• Revert "Re-order and use IndexerState to prioritize the indexer thread pool."
• Simplify locking the scheduler.
• Adapt index cleaner to scheduler.
• Rebase

• [DateTime Runner] Add from-zone, to-zone and 24-hour time conversion. Improve timezone lookups (i.e. identical zone names now return all matches). The zone name is now used instead of the abbreviation in matches.
• Rebase to current master.

Rebase around multiple zone matching, and some improvements.

In D16579#352887, @astippich wrote:

You're doing the exact opposite of what we're asking for.
Look, I'd love to merge the bug fix for the DISC property. But we need compatibility.
I'll give you another reason: KFileMetaData has basically required that users use the DISCNUMBER field until now. And now you want to change that without providing any suitable transition. That's not user-friendly.

In D16579#352788, @smithjd wrote:

• Use the de-facto Album Artist field name for APE tags.
  
  Since the discussion around this patch has also included the Album Artist field, add the changes required for this field to this review.

• Use the de-facto Album Artist field name for APE tags.

In D16579#352282, @bruns wrote:

In D16579#352279, @smithjd wrote:

I would instead recommend a tag editor that properly tags APE files, such as puddletag. APE-using formats are less mainstream than id3 using formats. Users with APE-using formats usually know WHY they use their format of choice, and will know there are potential support shortfalls such as non-compliant tagging software, or software that allows to circumvent the accepted tagging standard, and will know how to mitigate or avoid such issues. I must also point out that stricter tag field adherence is better for APE-using formats in particular, and is better for all tag-using formats in general.

Good luck "educating" every APE user, they will really like to be told they should do what you consider right.

I would instead recommend a tag editor that properly tags APE files, such as puddletag. APE-using formats are less mainstream than id3 using formats. Users with APE-using formats usually know WHY they use their format of choice, and will know there are potential support shortfalls such as non-compliant tagging software, or software that allows to circumvent the accepted tagging standard, and will know how to mitigate or avoid such issues. I must also point out that stricter tag field adherence is better for APE-using formats in particular, and is better for all tag-using formats in general.

I would also argue that accepting values from tag field names that have identically-purposed, widely-acceptable alternatives is irresponsible. Changing your tags to meet the standard then is a more viable course of action.

In D16579#352191, @astippich wrote:

In D16579#352147, @smithjd wrote:

In D16579#351910, @astippich wrote:

The ape tag tests fail with this patch, but the test is actually wrong in that regard. It tests for an empty disc number, which I haven't noticed before.
I've found references to both DISCNUMBER and DISC, so the safest way is probably to check both.
So please query both tags like it is already done for the album artist and adjust the taglibextractortest.

DISCNUMBER doesn't seem to be a valid (or widely used) field for APEv2.

More (Picard) information: https://picard.musicbrainz.org/docs/mappings

Also it appears Picard, Puddletag and ffmpeg use 'Album Artist', not 'ALBUMARTIST'. And the link I provided (https://wiki.hydrogenaud.io/index.php?title=Tag_Mapping) also lists 'Album Artist' not 'ALBUMARTIST'. The unit test file has an 'ALBUMARTIST' field that should be changed to 'Album Artist'.

Yes, maybe it's not widely used, but it is used. Kodi for example supports both reading from DISCNUMBER and DISC. If you use kid3 to edit the metadata of ape tags, the standard behavior is to actually to write to DISCNUMBER (and similar to ALBUMARTIST).
One thing I've learned when I digged into metadata of audio files is that there is no standard, and KFileMetaData should handle as much cases as possible. Since it is easy to query both, please add it.

• Change the unit test to check if the APE 'disc' value is correct.

In D16579#351910, @astippich wrote:

The ape tag tests fail with this patch, but the test is actually wrong in that regard. It tests for an empty disc number, which I haven't noticed before.
I've found references to both DISCNUMBER and DISC, so the safest way is probably to check both.
So please query both tags like it is already done for the album artist and adjust the taglibextractortest.

Useful tag mapping information:

• Re-write the file index scheduler. Combine content indexer suspend logic.
• Update the balooctl tool with the changed suspend/resume behaviour.
• Re-order and use IndexerState to prioritize the indexer thread pool.
• Newline and tab fixes.
• Prevent a scheduler race condition.
• Separate runnableStateChanged into two functors.
• Allow the first run indexer to complete before running any other runnables. Prevent the new file and unindexed file runnables from running at the same time.
• Revert "Re-order and use IndexerState to prioritize the indexer thread pool."
• Simplify locking the scheduler.
• Adapt index cleaner to scheduler.

In D15939#341728, @poboiko wrote:

In D15939#341094, @smithjd wrote:

https://phabricator.kde.org/D11529 was already up for review, implemented the index cleaner and checked for removeable volumes before removing index entries. Exporting the storagedevices object was required: https://phabricator.kde.org/D15047. The alternative, implementing a path lookup function is here: https://phabricator.kde.org/D15843.

Sorry, I was not aware of those patches (didn't do my homework). I'll look at those!

UPD: but will those help? I mean, if device is not present at the moment, Solid won't pop it up, and index entries will be forgotten.
It seems like it will help only if device is present, but not yet mounted.

https://phabricator.kde.org/D11529 was already up for review, implemented the index cleaner and checked for removeable volumes before removing index entries. Exporting the storagedevices object was required: https://phabricator.kde.org/D15047. The alternative, implementing a path lookup function is here: https://phabricator.kde.org/D15843.

Rebase.

https://bugs.kde.org/show_bug.cgi?id=353559

Rebase.

Rebase.

• Rebase.

• Re-write the file index scheduler. Combine content indexer suspend logic.
• Update the balooctl tool with the changed suspend/resume behaviour.
• Re-order and use IndexerState to prioritize the indexer thread pool.
• Newline and tab fixes.
• Prevent a scheduler race condition.
• Separate runnableStateChanged into two functors.
• Allow the first run indexer to complete before running any other runnables. Prevent the new file and unindexed file runnables from running at the same time.
• Revert "Re-order and use IndexerState to prioritize the indexer thread pool."
• Simplify locking the scheduler.
• Adapt index cleaner to scheduler.

• Re-write the file index scheduler. Combine content indexer suspend logic.
• Update the balooctl tool with the changed suspend/resume behaviour.
• Re-order and use IndexerState to prioritize the indexer thread pool.
• Newline and tab fixes.
• Prevent a scheduler race condition.
• Separate runnableStateChanged into two functors.
• Allow the first run indexer to complete before running any other runnables. Prevent the new file and unindexed file runnables from running at the same time.
• Revert "Re-order and use IndexerState to prioritize the indexer thread pool."
• Simplify locking the scheduler.
• Adapt index cleaner to scheduler.

Does this run at startup? If so, this will erase the entries of files on a removable volume not already mounted.

• [DateTime Runner] Show a date match if needed on conversion both to and from local

In D15843#334518, @ngraham wrote:

Perhaps we should discuss the implementation of multi-device indexing in a Phab ticket instead of across the comments of multiple patches. Then we can settle on an agreed-upon approach and go implement it instead of going in circles with different approaches.

As a side note - cross-device indexing is broken anyway and can never work reliably in the current scheme using device ids as part of the baloo document id. Device ids are not stable. For the home partition it works somewhat reliable as the device setup is sufficiently fixed, but for any network share, Vault, disk image, whatever, it depends on the mounting order.

I will keep opposing any changes trying to paper over it.

I have not had a problem with mounted external volumes. FYI, complain to the Solid people about the non-randomness of the udi. That isn't a fault of Baloo.

You clearly lack understanding of the problem. This is not about solid UDIs, but about device ids provided by the kernel (man 7 inode) . Complain to the Linux folks!?

There is no need for this, just create a new StorageDevices where you need it.
Creating a second StorageDevices instance in a process is quite cheap.

Creating a separate object cluttered the console with duplicated debug output and raised a threading error.

In D15843#334230, @bruns wrote:

Most obvious problem with this change - as far as I can deduce from your description, this is about runtime behaviour. The config class is the wrong place to add this method.

In D15843#334024, @bruns wrote:

Whats the use case exactly? "Some parts" is not sufficient ...

A slightly smarter approach would be for Plasma Vaults itself to add such a rule for whatever mountpoint is chosen during new vault creation.

xattrs are no good for vaults because the xattr is ignored for the mountpoint, only restored when the volume is unmounted.

What's wrong with a .balooignore file in the root of the vault? Tracker uses .trackerignore.

No, because even if the default umask is 002, or 022, POSIX says that the default permissions of a file on creation are going to be 0666, not 0777:

https://www.freedesktop.org/wiki/CommonExtendedAttributes suggests xattrs to use to store do-not-index information and also requires each file to be explicitly set to be indexed.

What was wrong with https://phabricator.kde.org/D15583?id=42018 ?

• [DateTime Runner] Add two new syntaxes for conversion to and from 24 hour time.

In D15718#330864, @ngraham wrote:

Making files executable that don't need to be executable is a bad security habit. What if the contents get replaced with something malicious? Suddenly that now-malicious file has execute permissions.

In D15718#330845, @ngraham wrote:

In D15718#330844, @smithjd wrote:

In D15718#330836, @ngraham wrote:

Wouldn't this have the effect of un-indexing most files? A quick check of my documents (text, word processing, excel, etc) reveals that none of them have the execute bit set. As-is, I think this would render Baloo mostly useless.

A default mask of 0002 or more permissive looks fairly common across distros, and is permissive enough to index files by default.

setfacl -d -m u::rwx ~ or umask 0022 will set default execute permissions on created files. You can set something less permissive on your downloads directory or plasma vault mount with setfacl -d u::rw or similar.

chmod -R 755 ~ will recursively give every file in your home directory execute permisions.

You are proposing fundamentally breaking Baloo and then requiring that users or distros clean up our mess for us by making all their files executable--in the process reducing their own security. Sorry, but this is simply unacceptable.

No part of this proposal makes any sense to me. We just can't do this.

In D15718#330836, @ngraham wrote:

Wouldn't this have the effect of un-indexing most files? A quick check of my documents (text, word processing, excel, etc) reveals that none of them have the execute bit set. As-is, I think this would render Baloo mostly useless.

Files/folders should not be automatically indexed if the execute bit is unset. Downloads from most if not all popular browsers are not executable by default.

Technically, this check isn't actually needed, though it does prevent the user from entering a path more than once. At first glance this looks like it should work:

if (folder.startsWith(path))

In D15341#323730, @ngraham wrote:

In D15341#323715, @smithjd wrote:

KRunner as a standalone application does much more than search for files. Therefore adding independent shortcut configurability isn't so hard to justify. Kicker/Kickoff and dolphin search text input shortcuts on the other hand are configurable globally already, and only perform a subset of what KRunner does.

Can you explain why the fact that KRunner does more than the search fields in Kicker/Kickoff and Dolphin is a justification for allowing you to customize a small subset of the navigation shortcuts there, but not elsewhere? Help me understand where you're coming from. If you'd want to use ctrl+e and ctrl+s (etc.) to navigate in KRunner, why wouldn't you want to use them elsewhere too? What's the difference?

In D15341#323704, @ngraham wrote:

In D15341#323672, @smithjd wrote:

Kicker/Kickoff and the dolphin search aren't full-fledged launchers like KRunner, only search fields for Baloo.

1. Kicker/Kickoff actually are: they're full-fledged interfaces to KRunner, with the exception that they have a semi-hardcoded list of enabled runners.
2. Not sure how that would make a difference anyway; the point is, if these navigation shortcuts are valuable for the KRunner input field, why wouldn't they be useful for every input field?

In D15341#322618, @ngraham wrote:

I appreciate the patch and the fact that you considered the prior comments in D14739. But I must admit I'm still left with a nagging question: "Why?"

Why here? Why not elsewhere? How about the search field in Kicker and Kickoff? The one in Dolphin? If this should be done at all, shouldn't it be done everywhere? And if it can't be done everywhere due to conflicts (i.e. because ctrl+a and ctrl+s have existing meanings in GUI software), then should it be done at all?

• [KRunner] Re-work the shortcut handling to allow modifying the shortcuts.

• New DBus method updateIndex().
• Document indexing options.
• Prevent a scheduler race condition.
• Rebase for separate statechanged functors.

• Revert "Re-order and use IndexerState to prioritize the indexer thread pool."

In D15047#314741, @bruns wrote:

In D15047#314485, @smithjd wrote:

In D15047#314477, @bruns wrote:

There is no need for this, just create a new StorageDevices where you need it.
Creating a second StorageDevices instance in a process is quite cheap.

Creating a separate object cluttered the console with duplicated debug output and raised a threading error.

Then your code is wrong anyway. This is lazy initialization, and if you can not not guarantee it is save to do so, don't do it.

Closing this because it breaks at least the settings:// ioslave, and the tags:// slave no longer has urls attached to the filename.

• New DBus method updateIndex().
• Document indexing options.
• Prevent a scheduler race condition.
• Run de-indexing file check in parallel.
• Rebase for separate statechanged functors.

Rebase.

Rebase.

• Re-write the file index scheduler. Combine content indexer suspend logic.
• Update the balooctl tool with the changed suspend/resume behaviour.
• Re-order and use IndexerState to prioritize the indexer thread pool.
• Newline and tab fixes.
• Prevent a scheduler race condition.
• Separate runnableStateChanged into two functors.
• Allow the first run indexer to complete before running any other runnables. Prevent the new file and unindexed file runnables from running at the same time.