<div dir="ltr"><div dir="ltr">Hi Charles,<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 18, 2021 at 4:00 PM Charles Plessy <<a href="mailto:charles-listes%2Bxdg@plessy.org">charles-listes+xdg@plessy.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">Le Tue, Feb 16, 2021 at 05:11:36PM +0100, Jehan Pagès a écrit :<br>
> <br>
> Hello all!<br>
<br>
Hello Jehan and everybody!<br>
<br>
> Typically someone reported an issue about GIMP taking over handling of<br>
> image types it supports every time it is installed/updated. So for<br>
> instance JPEG images were not displayed by default with a simple image<br>
> viewer anymore, but in GIMP.<br>
<br>
In Debian we are automatically translating Desktop entry files to<br>
Mailcap entry files, and we hit a similar problem: suddenly the Mailcap<br>
users would open PDF documents with GIMP by default…<br>
<br>
<a href="http://charles.plessy.org/Debian/debi%C3%A2neries/pdf/index.en.html" rel="noreferrer" target="_blank">http://charles.plessy.org/Debian/debi%C3%A2neries/pdf/index.en.html</a><br>
<br>
A change of the Desktop entry specification going in the direction you<br>
propose would allow us to give lower Mailcap priorities to programs<br>
declaring that they do not aim at being the default for a given media<br>
type.<br>
<br>
> So I would propose 2 fields with the same syntax as MimeType field:<br>
> <br>
> - NativeMimeType: the list of mime types which can be considered as the<br>
> native formats of the software. For instance for GIMP:<br>
> <br>
> - IntentMimeType: the list of supported mime types which can be considered<br>
> of the same nature as the native mime types, the same "intent" files.<br>
<br>
One downside with this approach is that if you update GIMP's Desktop<br>
entry file and it is read by a program that is not supporting the<br>
proposed new version of the specification, the most important media<br>
types might be ignored.<br></blockquote><div><br></div><div>I thought about it too, and this is why I was proposing the NativeMimeType and IntentMimeType as additional, not replacement (but it must have been lost in the many emails). In particular, it means that XCF MIME types will be both in the historical MimeType and the new NativeMimeType fields.</div><div><br></div><div>Same PSD or ORA would be both in MimeType and IntentMimeType.</div><div><br></div><div>This way, the problem you raise will simply not happen because a program which only supports the old format of the spec will still see XCF, PSD and ORA in the MimeType list.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Instead, how about having a new field (for instance ExtraMimeType) for<br>
indicating the lower-priority media types.  Then software like GIMP<br>
could "demote" them in the new field, and at worse if the new field is<br>
not parsed, then the native or intended types will still be recognised.<br></blockquote><div><br></div><div>If we do this, we change the meaning of MimeType field for these programs and we actually create the problem you mentioned for the other (out-of-intent) formats. Indeed we usually don't want GIMP to be the default for PNG, JPEG, PDF or SVG. Usually we have a much better default for all of these.</div><div><br></div><div>But sometimes when there is absolutely no other software handling these formats, GIMP still is a nice fallback (better than nothing). This happens for very old formats for instance (GIMP still has support of some very old/weird formats and we don't intend to get rid of these supports), which no image viewer care to support nowadays.</div><div>It also happens for some very specialized formats (used in specialized fields like some video game image formats).</div><div>And finally it happens with very recent formats. For a while for instance, I believe the only software in Linux able to show WebP images was GIMP (now also at least on Firefox and Chrome|ium). Right now, I think AVIF images might only be viewable in Chrome|ium and GIMP. As for HEIC images, I still haven't found any other software on Linux, but GIMP of course, to display them.</div><div><br></div><div>So even though all these MIME types are not GIMP primary intent, it's still nice that programs supporting the old desktop spec only would know that GIMP can at least serve as a suitable fallback.</div><div><br></div><div>In other words, my proposition does not change at all the meaning of the "MimeType" field (still means "this software can 'open' these MIME types" with "open" being a broad range of meaning), but it adds 2 semantic fields meaning "what we are really meant to do is editing image projects with these formats".</div><div><br></div><div>Last but not least, if we go with your idea, the MimeType field becomes a de-facto NativeMimeType field and would therefore always get top priority. Say now that an image viewer gets XCF, PSD and ORA display support (which is a fine feature to have). Then it would add it in its MimeType which could override the MimeType of GIMP. And now when you click these work images, your viewer is run instead of your specialized work program.</div><div>On the other hand, when I make the Native|IntentMimeType fields something special of their own, we explicitly say "yeah these are particular", and when any program has such fields, these take priority over normal MimeType.</div><div><br></div><div>Basically MimeType still is the normal field and most programs would have nothing to change. An image viewer should not move all images mime types it supports into Native|IntentMimeType. These fields will be used only for specialized software.</div><div><br></div><div>Does it make sense? 🙂<br></div><div><br></div><div>Therefore: a desktop parsing program doesn't support the old spec and/or a given program devs haven't updated the .desktop file? No prob, it works like before. The desktop parsing program supports the new spec and a given program devs added the 2 fields? You get nicer additional hints to get slightly better default file association.</div><div><br></div><div>Jehan<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Have a nice day,<br>
<br>
Charles, maintainer of the mailcap and media-types packages in Debian.<br>
<br>
-- <br>
Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan<br>
Tooting from work,           <a href="https://mastodon.technology/@charles_plessy" rel="noreferrer" target="_blank">https://mastodon.technology/@charles_plessy</a><br>
Tooting from home,                 <a href="https://framapiaf.org/@charles_plessy" rel="noreferrer" target="_blank">https://framapiaf.org/@charles_plessy</a><br>
_______________________________________________<br>
xdg mailing list<br>
<a href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/xdg" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/xdg</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">ZeMarmot open animation film<br><a href="http://film.zemarmot.net" target="_blank">http://film.zemarmot.net</a><br>Liberapay: <a href="https://liberapay.com/ZeMarmot/" target="_blank">https://liberapay.com/ZeMarmot/</a><br>Patreon: <a href="https://patreon.com/zemarmot" target="_blank">https://patreon.com/zemarmot</a><br>Tipeee: <a href="https://www.tipeee.com/zemarmot" target="_blank">https://www.tipeee.com/zemarmot</a></div></div>