New `MimeType` fields in .desktop

[Bollinger, John C]

Hi All,

On Monday, February 22, 2021 4:09 AM, Jehan Pagès wrote:

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

Yes, this is part of what I had in mind when I questioned whether the proposal really achieved the stated objective.

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.

Not so fast.  This was the point of my hypothetical example of a second full-featured image editor that also uses XCF as its native format.  Such an editor would also have XCF as its NativeMimeType, so again, who gets chosen as the default? To be sure, I am not aware of such a GIMP alternative existing now, but there are such conflicts now for some other MIME types, and there could be one for the GIMP in the future.

Whatever means might be defined for desktop files to convey MIME-handling capability, intent, or priority, as long as desktop file production and management is decentralized, there is no reliable way to avoid such conflicts.  Adding features to the desktop file format might well provide part of a solution, but it cannot provide a complete solution.

In one sense, that's obvious on its face, for whatever information appears in desktop files has no effect unless software reads and acts on it.  But part of my point is also that without some form of centralized curation of desktop files -- which seems unlikely to happen -- there cannot be enough information in those files to solve the problem reliably.  And as long as we assume that desktop file creation and management will be decentralized, we should take care about what kind of information we try to express there.  Software capabilities, yes.  Intents, ok.  Quality of support measures, maybe.  But priority relative to alternative applications? That needs to rely at least in part on data sources and / or software specifications separate from desktop files.

It remains unclear to me why few distributions seem to use XDG's existing, designated mechanisms for specifying which applications to prefer as default handler for various MIME types.  Are they insufficient in some way?  I suppose they must be, but if not, then what role would XDG in fact have to play here?  On the other hand, if the existing mechanisms indeed are insufficient then how so?  Some observations have been made about this, but none that I find conclusive.

Overall, my point is that any proposal to address the problem via (only) a change to the desktop spec is incomplete and probably premature.  Some kind of change to the desktop spec may well be warranted, but any such change is far more likely to yield the desired fruit as part of a broader revision to the specifications for the data sources and tools relevant to this space.  Moreover, it's not even clear to me exactly what is the desired result here, in a sense that could be addressed via specifications.  No one seems to disagree that there is a problem to be addressed here, but is there as much agreement on the characteristics desired of a solution?


Regards,

John




________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210222/d2d8c834/attachment.htm>