Hello Developers, once more I ask for your expert input on how to do things properly.
I recently made this, which basically is just a .desktop file I need to install in the right place. Sounds simple I thought, let’s do that.
The solution turned out as a Rube Goldberg machine, and I wanted to ask your input about all the components involved.
Basically I have two locations where this can live:
-
/usr/share/applicationssystem-wide -
~/.local/share/applicationsper-user.
Now, we do not install stuff into $HOME from packages on principle. But this for later.
But. If I install to the system-wide location this works as long as the user does not have custom .desktop files in their local location. As soon as they do (and there are apps like mimer and others which put things there), the system-wide settings are not used at all any more.
So it seems the content of the .desktop files is not merged between the two locations, but the user directory overrides the system one completely.
Note that this is about MIME handlers only, NOT application launchers.
Test case:
create a .desktop file in `/usr/share/applications` (as root)
run update-desktop-database (as root)
test effect of that desktop file ( --> should work)
put another .desktop file in `~/.local/share/applications` as user
run `update-desktop-database ~/.local/share/applications` as user
test effect of that desktop file ( --> new file shows up, system one does NOT)
Question 1: is my observation here correct, or is it something that’s caused by my configuration/test environment?
Okay, so I decided that the place to put it was NOT the system-wide location, but per-user.
This means I need some kind of user application. As in my case I do not have a GUI app or component, I wrote a settings page in QML.
The settings app uses gconf (QML ConfigurationGroup) values to track enabling/disabling of the function.
Question 2: Is there a way to create/remove such a MIME handler .desktop file from pure QML in System Settings?
I have not found a way to do so, except through writing a proper application, or using python. I did not want to do that because that would either add a dependency on python, or require something to be compiled which would be architecture-specific).
But I did find I can call the DBus SessionBus to start/stop a systemd service in user context. Fine, great, this should handle all the home location, user name etc stuff for me. Nice.
So we add a .service file to /usr/lib/systemd/user without an [Install] section, to be called on demand as a oneshot/simple service. (BTW, do we install into /usr/lib/systemd/ or /etc/systemd/?)
So we make a little shell script to be executed by the .service file, and can now add/remove the .desktop file in the user-specific place and can call update-desktop-database in user context too.
Putting it all together, and it works – but somehow I feel it’s not the ideal solution…
Question 3: In general, it seems there is no commonly agreed-on way to handle app-specific protocol and filetype handlers, and especially for users to enable/disable. Can we “standardize” on something like that?
Just a suggestion: I decided to add a new System Settings category and page (unimpressive details here).
In theory, that could be adopted by other apps, so they don’t have to do it from their GUI/daemon/other.
It would IMO improve usability for the user on the one hand (e.g. find all OpenWith and maybe also Sharing Plugin things there), and also make it easier for App Devs to just “register” their custom handlers there and have a standard way to enable/disable them in a user-agnostic way.
Is there any interest in doing it this (or a similar, better) way?