Thank you for the clarification. I'll try to ask about this in email@example.com
If it turns out that I have misunderstood the specification or if they decide to change it, let me know and I will update mimeo.
I'm currently stuck trying to make mimeo open tmsu:// uris with my custom scheme handler. This is odd because mimeo used to do this fine -- and "gnome-open tmsu://q/foo" still works fine, and directly invoking "~/bin/tmsu-schemahandler.sh tmsu://q/foo" works fine.
Anyone got an idea what the cause might be here?
Details are as follows:
* "mimeo -m tmsu://q/foo" correctly returns "x-scheme-handler/tmsu"
* "mimeo -m | grep tmsu" correctly(?) returns "x-scheme-handler/tmsu"
* "mimeo -c tmsu://q/foo" or "mimeo tmsu://q/foo" return errors "failed to determine command(s) for tmsu://q/foo"
* Creating a new minimal desktop file using mimeo appears to work: "mimeo --create testify.desktop 'tmsu-schemahandler' '/home/kau/bin/tmsu-schemahandler.sh %u' x-scheme-handler/tmsu ''. The result (~/.local/share/applications/testify.desktop) is as follows:
[Desktop Entry] Type=Application Name=tmsu-schemahandler Exec=/home/kau/bin/tmsu-schemahandler.sh %u MimeType=x-scheme-handler/tmsu; Terminal=false NoDisplay=true Comment=Created by Mimeo
* Adding it to ~/.config/mimeapps.list via `mimeo --debug --prefer x-scheme-handler/tmsu testify.desktop` works (a record is added)
* However, "mimeo -c tmsu://q/foo" or "mimeo tmsu://q/foo" still returns errors "failed to determine command(s) for tmsu://q/foo"...
* and "mimeo -d tmsu://q/foo" returns "None"
Have you tried using the "--deprecated" option? ~/.local/share/applications is no longer supported by the standard but the current standard provides no replacement location for custom desktop files. Several common openers still use the deprecated directories which is probably why they still work.
You could also use a custom association file instead of a user-created desktop file. See "mimeo --assoc-help" for details.
Thanks for the quick response!
--deprecated works... (seems pretty broken that the current standard doesn't have a location for custom desktop files!)
Association file also works (I was avoiding that because I thought there was a 'more correct'/universal way to fix it)
seems pretty broken that the current standard doesn't have a location for custom desktop files!
I agree. I don't get the thought process there either. It seems like one of those cases where someone got lost following some warped ideal and left practicality behind.