Register AppImages as URL handlers
TheAssassin opened this issue · 28 comments
This is a proposal to make appimaged and the desktop integration application set up a URL handler for certain AppImages which are able to handle URLs. Such AppImages are e.g. browsers, or the Red Eclipse one I maintain.
As far as my short research on this goes, it should be fairly easy to implement: Just append a line to ~/.local/share/applications/mimeapps.list. We'd have to somehow keep track of it, however, but we could do that by adding a comment clearly stating that it's an AppImage related entry, and some way to be able to identify it again as being related to an AppImage.
A problem I found is that this might easily override default URL handlers, and thus might create some clutter. We'd probably have to blacklist certain handlers.
All in all I think it's a really cool feature, and might come in handy for many applications.
Just to understand your proposal correctly, you would want to make a Transmission AppImage open magnet links, for example? I think the optional appimaged daemon should be able to do that already today, and if it doesn't, I'd consider it as a bug. Or is it something else you are suggesting?
(As a side note, klik had klik:// links... that, when clicked, would assemble an "AppImage" from existing deb packages by running a recipe on your local machine...)
Just to understand your proposal correctly, you would want to make a Transmission AppImage open magnet links, for example?
Yes, that's the idea.
I think the optional appimaged daemon should be able to do that already today, and if it doesn't, I'd consider it as a bug. Or is it something else you are suggesting?
Even if it did, the default desktop integration should do it, too.
Ideally we would make it reuse the very same functions that appimaged uses, no?
Well, if it's possible, sure. We could anyway just extract common functionality in an extra C library, which is then statically linked into appimaged and the new desktop integration.
...or simply include common.c :-)
... which should be split up a bit to a set of smaller files in my opinion.
Also, I hate redundancies during compile time. With CMake, creating a library and linking to it is the way to go, instead of having to add the same set of common files to more than a target.
Dynamic linking would be possible then as well, and might save some space when using the code in more than one place, although this scenario is rather unlike for appimaged and the desktop integration (except for appimaged's AppImage).
What is the difference in the end result of static linking vs. including?
It's most likely negligible, if any. I assume the biggest difference is the order of the routines in the final executable, if the compiler which links the final binary doesn't change it anyway. Also, some really old compilers may not clean up unused routines etc., but that goes for "normal" compilation as well (.c becomes .o, .os are combined to an executable). Static libraries are technically spoken nothing other than archives of those .o files.
I guess it's a matter of personal preference. I try to apply DRY wherever possible.
I think the optional appimaged daemon should be able to do that already today, and if it doesn't, I'd consider it as a bug. Or is it something else you are suggesting?
@probonopd I can't find the code for that, and had some trouble (#476) getting appimaged to work (my CMake configuration doesn't work for appimaged yet, working on it). Could you post a link to it please?
I don't see how to use this for an AppImage. Is there any documentation on it? I just don't think it's there yet.
MIME types that are supposed to be opened are in the desktop file, which appimaged copies. Then, there are XML files that bring new MIME types into the system, I think appimaged also copies them. Or which file do you think appimaged should handle which it doesn't?
I am not sure how this is supposed to work. Until now, to make URL handlers work, I've appended them to the file mentioned in the original post. Could you post a MWE?
According to e.g., https://edoceo.com/howto/xfce-custom-uri-handler, putting the X-Scheme-Handler MIME type into the Desktop file declares support for a scheme. However, a registration in the file ~/.local/share/applications/mimeapps.list is still necessary. (It isn't even really necessary to declare the MIME type in the Desktop file in my experience, as long as the file is mentioned in mimeapps.list). Therefore, this features is definitely not implemented.
I hope mimeapps.list is/can be autogenerated somehow?
The single entries are easy to generate, you could easily build them from the Desktop files in the AppImages. The problem is that the list is used by the system, too, and might even contain manual entries.
I think we'd have to add a comment to every line managed by appimaged to indicate it shouldn't be edited/deleted, and to allow it to be found again in case an AppImage is deleted from the system. appimaged has such a system implemented for Desktop files already (although there it's used in the filenames), but I guess the same method could be used to match lines in mimeapps.list to AppImages.
I can confirm that URL handlers work fine after updating mimeapps.list.
The easiest way to do this is with xdg-mime. (syntax: xdg-mime default appimagekit_<md5sum>.desktop <scheme defined in the .desktop>). Individual AppImages can call this from their AppRun script (after identifying the desktop file installed by appimaged) as a workaround until this is supported upstream.
It should suffice if you'd add the handler as a MimeType to the desktop file, and then call update-desktop-database .local/share/applications. Could you please test this? It'd be a more elegant solution, as the integration code could just call this command in the future.
(Please beware you will have to remove the association before from the file in .local/share by hand, though.)
Ah, probably because the MIME type is not known to the system.
How did you test the association? Did you try xdg-mime query default <url handler> as well?
Apologies - I initially commented saying that i had previously tested that, but deleted the comment immediately after posting when I realized that this testing was with an earlier version of my AppRun that likely had other issues that affected it.
Repeating it now, I can confirm that update-desktop-database does seem to work.
(Just for the sake of completeness) CC #653.
@pchote next time, just edit your comment, please. You can remove the entire content, or add ~~ to strike it out, or something.
Many of us receive notifications via diverse channels, and this always causes inconsistencies, as you guessed right.
xdg-mime default appimagekit_<md5sum>.desktop <scheme defined in the .desktop>
@TheAssassin would you like to implement this in libappimage and/or appimaged?
No. Instead, update-desktop-database should take care of adding applications for specific MIME types (which will become default if there are no other applications). I think libappimage shouldn't change the default behavior and change default apps. Normal system installations won't do that either.
Right! Are we currently already running update-desktop-database?
No. See #653.
Can we close this one?
Nope. Part of AppImageCommunity/libappimage#23.