fernschreiber overrides https:/ and tg:/ mime handlers

[elros34]

After first start fernschreiber creates harbour-fernschreiber-open-url.desktop in ~/.local/share/applications and run update-desktop-database as user thus all mime handlers which use x-scheme-handler/https (some apps) or x-scheme-handler/tg (depecher) and are installed in /usr/share/applications/ are now ignored by xdg-open and Open file dialog. Also removing application doesn't clean up mess in ~/.local/share/applications/ directory.

I know this is old way to fool harbour rules used by some apps but please do not enable such a behavior by default.

[Wunderfitz]

Yep, a well-known issue - sorry for the inconvenience! Ideally, Jolla comes up with a solution to integrate properly with the MIME handlers in a Harbour-compatible way without harming other apps. But as that's unlikely we probably need to find a proper solution which everybody can live with:

1. Fernschreiber would probably need to ask before actually adding itself to the MIME types
2. If it does integrate, the existing ones from the main directories should be copied over to keep on working, right? (I'm anyway wondering why the different valid XDG directories are not merged by the system)

However, from my point of view there are still open questions:

• What if you install another app afterwards that registers http, http or tg via a file in the standard location?
• The ~/.local... variant is a perfectly valid way of registering. Why should apps bother which one to choose?

Until this is fixed entirely, there is the possibility to remove the changes made by Fernschreiber by going to its Settings and uncheck the "Integration with Open-With menu" option. If there are still problems, you can try https://openrepos.net/content/llelectronics/mimer

[elros34]

A few popular apps use same approach so I don't see any proper solution except merging mimeinfo.cache from both directories (maybe also /usr/local/share/applications/) in libcontentaction. Asking about adding fernschreiber to MIME types at first start or just keep it false by default is perfectly fine solution for me.

If you really want to handle it for all cases and don't plan do upload it to harbour then yes copying is the workaround

• Put harbour-fernschreiber-open-url.desktop in /usr/share/applications in rpm
• Only if ~/.local/share/applications/mimeinfo.cache already exist there and user want to do such a operation, copy harbour-fernschreiber-open-url.desktop and all .desktop files which registers for same MIME types

~/.local/share/applications/mimeinfo.cache takes precedence of /usr/share/applications/mimeinfo.cache so installing other apps which register https will not help.

[jgibbon]

This seems to belong to a bunch of related issues: #151, #276, #312, #412 (this comment is copied to all of them) Proposed way to hopefully fix most of them:

• use MimeType=x-url-handler (caveat: according to link, update-desktop-database isn't called after installation yet…)
• implement at least some of the missing url functions (link in #312 – search for LocalUrlHandlers; also look below)
• on start: scan for existing .desktop file, delete.
• link handler: save "active link" to some temporary property until tg is authenticated, only then process it.