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 <[email protected]> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/xdg >
_______________________________________________ xdg mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/xdg
