<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Hi,<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>The "Host" value is one of two things:<br></div><div>- a reverse DNS name declaring the host application type.<br></div><div>- a path to an executable<br></div><div><br></div><div>Some examples of host application types could be:<br></div><div>- org.freedesktop.defaultapp.Browser<br></div><div>- org.freedesktop.defaultapp.Terminal<br></div><div><br></div><div>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:<br></div><div><br></div><div>1.<br></div><div>    # org.freedesktop.defaultapp.Terminal<br></div><div><br></div><div>    Exec=alacritty -e<br></div><div><br></div><div>2. Just a symlink to a desktop entry or executable on the system.<br></div><div><br></div><div>This would allow for:<br></div><div>- Setting the default terminal<br></div><div>- 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.<br></div><div><br></div><div>Thoughts?<br></div><div><br></div><div>On Fri, Jul 10, 2020, at 09:57, Emmanuele Bassi wrote:<br></div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div dir="ltr">On Fri, 10 Jul 2020 at 10:08, David Edmundson <<a href="mailto:davidedmundson@kde.org">davidedmundson@kde.org</a>> wrote:<br></div><div class="qt-gmail_quote"><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div dir="ltr"><div><br></div><div class="qt-gmail_quote"><div><div>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.<br></div><div><br></div></div></div></div></blockquote><div><br></div><div>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.<br></div><div> <br></div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-color:rgb(204, 204, 204);border-left-style:solid;border-left-width:1px;padding-left:1ex;"><div dir="ltr"><div class="qt-gmail_quote"><div><div>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. <br></div></div></div></div></blockquote><div><br></div><div>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): <a href="https://gitlab.gnome.org/GNOME/glib/-/issues/338">https://gitlab.gnome.org/GNOME/glib/-/issues/338</a><br></div><div><br></div><div>The idea of using a special MIME type handler was rejected (by one of the maintainers of the shared-mime-info database) here: <a href="https://gitlab.gnome.org/GNOME/glib/-/issues/338#note_205947">https://gitlab.gnome.org/GNOME/glib/-/issues/338#note_205947</a><br></div></div><div><br></div><div>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.<br></div><div><br></div><div>Ciao,<br></div><div> Emmanuele.<br></div><div><br></div><div>-- <br></div><div dir="ltr" class="qt-gmail_signature"><div><a href="https://www.bassi.io" target="_blank">https://www.bassi.io</a><br></div><div>[@] ebassi [@<a href="http://gmail.com" target="_blank">gmail.com</a>]<br></div></div></div><div>_______________________________________________<br></div><div>xdg mailing list<br></div><div><a href="mailto:xdg@lists.freedesktop.org">xdg@lists.freedesktop.org</a><br></div><div><a href="https://lists.freedesktop.org/mailman/listinfo/xdg">https://lists.freedesktop.org/mailman/listinfo/xdg</a><br></div><div><br></div></blockquote><div><br></div></body></html>