Hi! On Mon, Feb 22, 2021 at 10:06 AM Charles Plessy < charles-listes+...@plessy.org> wrote:
> > On Thu, Feb 18, 2021 at 4:00 PM Charles Plessy > > > > > Instead, how about having a new field (for instance ExtraMimeType) for > > > indicating the lower-priority media types. Then software like GIMP > > > could "demote" them in the new field, and at worse if the new field is > > > not parsed, then the native or intended types will still be recognised. > > Le Thu, Feb 18, 2021 at 04:51:49PM +0100, Jehan Pagčs a écrit : > > > > 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. > > > > But sometimes when there is absolutely no other software handling these > > formats, GIMP still is a nice fallback. > [...] > > 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. > > Hi Jehan, > > I think that you underlined the tradeoff well. > > We can keep full backwards compatiblity at the expense of a more complex > procedure. The issue I have with your proposal is that a large number > of media types will be listed twice in each Desktop entry, and it > complicates parsing for those who want to extract information about > priority. > > But partially breaking compatibility as I propose is not good for people > installing by themselves new applications on old desktop systems during > the transition, as they will not see the application listed as capable > to open all the media types it supports. > I re-read my email and realize it's not just the transition period or the backward compatibility. My last example about an hypothetical viewer which would have XCF display support shows the problem even after the transition period, when all software would have updated their desktop file. Let me show with your proposal (I don't write real MIME types, because I'm lazy and we all understand anyway): - GIMP would have: MimeType=XCF / ExtraMimeType=JPG,PNG,PDF - A viewer would have (with XCF support): MimeType=XCF,JPG,PNG,PDF Here XCF is just on the same level as JPG/PNG/PDF for the viewer (it is just another displayable format, it has conceptually no more or less a meaning, hence stays in the same field). Who gets default handling of XCF? We end up in the same situation as now, and it could be GIMP or the viewer according to whatever more-or-less-random/arbitrary algorithm (no way to know otherwise), because it looks like we are saying that the viewer has all these formats as its native support. Or else, we could make here again some even-more complicated algorithm (considering the fact that viewer has no ExtraMimeType, but GIMP has, we consider MimeType of GIMP as higher priority; but what if the viewer ever had an ExtraMimeType field for some other formats?). In my proposition: - GIMP would have: MimeType=XCF,JPG,PNG,PDF / NativeMimeType=XCF - A viewer would have (with XCF support): MimeType=XCF,JPG,PNG,PDF Well here absolutely no indecision. Only one of them has the very semantic NativeMimeType. It obviously takes precedence over XCF support. So it looks to me like we get better transition + backward compatibility + better end-result, no? 🙂 Jehan > Whichever solution gets consensus, I would be happy to see things moving > forwards. > > Have a nice day, > > Charles > > Maintainer of the mime-support, media-types and mailcap packages in Debian. > > -- > Charles Plessy Nagahama, Yomitan, Okinawa, Japan > Tooting from work, https://mastodon.technology/@charles_plessy > Tooting from home, https://framapiaf.org/@charles_plessy > -- ZeMarmot open animation film http://film.zemarmot.net Liberapay: https://liberapay.com/ZeMarmot/ Patreon: https://patreon.com/zemarmot Tipeee: https://www.tipeee.com/zemarmot
_______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg
