<div dir="ltr"><div dir="ltr"><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thayne McCombs</div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 8, 2021 at 2:42 AM David Faure <<a href="mailto:faure@kde.org">faure@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On samedi 8 mai 2021 08:08:17 CEST Thayne wrote:<br>
> On Fri, May 7, 2021 at 8:35 AM Marc Pervaz Boocha <<a href="mailto:mboocha@sudomsg.xyz" target="_blank">mboocha@sudomsg.xyz</a>><br>
> <br>
> wrote:<br>
> > Another option is maybe have an option in the the definition of<br>
> > mimetypes xml files to have some kind of derivation. So all text/xml is<br>
> > will be marked as text/plain for applications.<br>
> <br>
> that seems more complicated to me than a system that uses the default app<br>
> for text/* if there isn't one assigned for text/xml at the same level, and<br>
> I'm not sure what the benefit is. Note that I'm only proposing that the<br>
> wildcard would be allowed as the entireity of the type after the slash.<br>
<br>
text/* kind of makes sense, but image/*, video/* or application/* doesn't, <br>
there's no application that can for sure handle all of that.<br>
So instead of a one-use-case wildcard support, the mimetype spec has support<br>
for inheritance. If you associate any application with text/plain then it WILL <br>
be associated indirectly with all text/* mimetypes.<br></blockquote><div><br></div><div>application/* definitely doesn't make sense. But image/* and video/*  definitely do (as in I want to use application X to open any image type by default, unless there is something more specific). I guess there is a question of how to set up something where you have a viewer for image/*, but then have some more niche formats opened by specific applications, such as image/xcf with gimp.<br></div></div></div>