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
