XDG Default Applications specification proposal

[Dasith Gunawardhana]

Hi,

Windows recently introduced their "Hosted Apps" model. I think a similar concept will work well for this problem. It would require an extension to the Desktop Entry Specification and a new Default Apps Specification.

If an application requires another application as an executor or runtime, i.e. a "host", it has the "Host" key defined in its desktop entry.

The "Host" value is one of two things:
- a reverse DNS name declaring the host application type.
- a path to an executable

Some examples of host application types could be:
- org.freedesktop.defaultapp.Browser
- org.freedesktop.defaultapp.Terminal

For each host application type we create a file in the directory "$XDG_CONFIG_HOME/deault-apps" with the same reverse DNS name. Some ideas for what that file would look like:

1.
 # org.freedesktop.defaultapp.Terminal

 Exec=alacritty -e

2. Just a symlink to a desktop entry or executable on the system.

This would allow for:
- Setting the default terminal
- Creating desktop entries for non-applications like individual web pages, PWAs, or scripts, all with the executor determined at runtime, instead of being predefined in the desktop entry.

Thoughts?

On Fri, Jul 10, 2020, at 09:57, Emmanuele Bassi wrote:
> On Fri, 10 Jul 2020 at 10:08, David Edmundson <davidedmundson at kde.org> wrote:
>> 
>> I don't like the idea of duplicating configuration for the options where it's already solved with mimetypes. If we have two "sources of truth" for the same thing, it can get complicated quickly.
>> 
> 
> A terminal isn't a handler for any MIME type, or any URI, and adding fake MIME types isn't going to scale either—it's just kicking the can down the road when we have to keep adding new fake MIME types and hope that stuff works.
> 
>> There's an idea in the annex "Use a new mime type (ex: x-default-handler/*) instead of a new list". Can you expand on why you didn't pursue that approach? It seems a lot easier to adopt. 
> 
> The whole discussion started off because GLib developers do not really want to add a settings key for this; it's a bad option, for us, as it falls apart when it comes to system and vendor overrides, and it plays really badly in mixed systems (e.g. GNOME applications can't really read KDE settings, and vice versa): https://gitlab.gnome.org/GNOME/glib/-/issues/338
> 
> The idea of using a special MIME type handler was rejected (by one of the maintainers of the shared-mime-info database) here: https://gitlab.gnome.org/GNOME/glib/-/issues/338#note_205947
> 
> Having a separate, neutral way to associate default applications that do not open files/URIs seems perfectly legitimate to me; modelling it on the MIME type handler means we can reuse a lot of the concepts, if not the implementations.
> 
> Ciao,
>  Emmanuele.
> 
> -- 
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20200710/15b73d96/attachment.htm>