Yep, I really don’t understand why people use baloo without content indexing…if you do that other means like your fd or even mlocate will probably be better solutions if all you need is filename search. KDE integration is really the only advantage left then…and I don’t really see much need of creating bookmarks/folderviews with filename searches, you hardly ever have reoccurring searches for the same filenames.

Baloo only makes sense to use with content indexing in my view…and there it hardly has any equal. I personally can’t be without this feature anymore. I use it actively since KDE4 days (anyone remembering nepomuk?) and my whole workflow is built on it.

For me the real advantages of baloo are metadata search and KDE integration.

Searching for tags with baloosearch6 tag:<tag> is something I use rather often, I even use the star ratings in baloosearches with rating>=6. Combine that with a mimetype and and you have a quick playlist of all music you rated with 4 or more stars in dolphin: baloosearch rating>=8 AND type:audio.

I also using baloosearch for images…the width and height keys are really useful for finding textures with specific dimension…something like baloosearch type:image AND Width>=2048 AND Height>=2048

And the of course the KDE integration that makes this really useful…you can use baloosearch queries everywhere in KDE, in open-file dialogs, as bookmarks in dolphin or file-dialogs, for desktop widgets showing folders…you can easily create an activity that has several folder-views on the desktop each showing a different set of files with specific tag…so left folder-view showing all files tagged “WIP” while right folder-view shows all files tagged “Finished” (To use queries in KDE you need them in the form baloosearch:/?querry=<the querry as you would use it in balooserarch6>

Edit:I wrote a reddit post some years ago about this…hope linking reddit is okay here: https://www.reddit.com/r/kde/comments/pmcshj/tip_baloosearch_kioslave/

I was wondering too why anyone would ever want this…but the proposal explains it:

Support for UEFI on MBR was originally added in blivet#764 to accommodate cloud image use cases, such as AWS, which at the time did not support UEFI booting on GPT disks. These constraints no longer apply to modern cloud platforms, making MBR-based UEFI setups unnecessary for current Fedora deployments.

So basically it was some workaround a few years ago. I have a hard time to see any reason speaking against the removal.

Just to make this clear (Sorry if it’s unnecessary, but maybe still useful info for others)…Path= lines in .desktop files are not related at all to the $PATH environment variables. They do something completely different (And yes, picking Path as key was a terrible choice in my view). Path= lines in .desktop files change the current working directory…they do about the same as a cd <directory> in a shell.

They do not change where a .desktop file looks for executables…only indirectly if a executable runs another file relative to the current directory or looks for images/icons/audio/other data relative to the current working directory.

And I have no clue why it doesn’t work with TryExec…the desktop file spec doesn’t mention anything about that :( ( https://specifications.freedesktop.org/desktop-entry-spec/latest/recognized-keys.html )

Try adding a PATH=/home/werecat/Grayjay line to your .desktop file. Without it the application will run with your home directory as your working-directory…and there the data files are missing (Why you need to copy them to your home). The path entry makes the program work in /home/werecat/Grayjay where the data directories actually are.

Edit: That is assuming when you started it manually you did a cd Grayjay and a ./Grayjay or similar. So you changed your working directory there first before starting it. If that is not the case ignore my post ;)

I imagine the “update from another system” path runs in troubles with more complex gentoo installs than just the base system. For a full update from the live disk it will have to include lots and lots of (often exotic) tools that might be used in the building process (document generators like doxgen, lexer, testing frameworks, several build systems and make-likes. programming languages…) in addition to being able to build against the already installed updates for packages while not accidental building against packages that are not updated yet.

Or you go the simpler way and only do a base update from the live-system…only update the base build system and package management of the gentoo system and afterwards boot in a “broken” system in which only the basics works and rebuild it from there.

For be both those options sound less desirable than what is suggested in the blog.

Cautionary