New `MimeType` fields in .desktop

[Jehan Pagès]

On Wed, Feb 17, 2021 at 5:32 PM Bollinger, John C <John.Bollinger at stjude.org>
wrote:

> On Wednesday, February 17, 2021 9:53 AM, Thomas Kluyver <
> thomas at kluyver.me.uk> wrote:
>
> I can see what you're saying, but I don't think it's ridiculous to suggest
> that a desktop file could encode some indication of how well an application
> handles a particular file type. You could think of this as describing 'can
> open' vs 'can import'. A few more examples from my laptop of technically
> possible matches that you probably wouldn't want to be used by default:
>
>
>    - Libreoffice Writer & text/plain
>       - Libreoffice Draw & application/pdf
>       - Pinta (bitmap graphics editor) & image/svg
>       - File roller (archive manager) & application/x-chrome-extension
>
> I don't have a problem in principle with giving desktop files a way to
> express a quality of support measure for the various MIME types they can
> handle.  That's about the capabilities of the software, not about system
> policy, notwithstanding that tools that implement policy could rely on such
> data in making decisions.  But that's qualitatively different from Jehan's
> proposal as I understand it.
>

You didn't understand. Thomas and Jan's answers are spot-on the kind of
discussions I was looking for by posting here. They perfectly understood
the proposition, whereas your answers are quite off-topic. Cf. my earlier
email, where I tell your answer is confusing and that you didn't
understand, but you just went on going even more off-topic assuming or
talking about unrelated stuff.

Jehan


> In particular, I don't envision that if such a mechanism were implemented
> in the spec and software, and used as intended by the GIMP, that it would
> in fact satisfactorily resolve the issue that motivated the proposal.
>
> In my experience, things like this haven't really come up, so I'm inclined
> to agree with you that it doesn't warrant changing the standard. But I
> think it's better to understand what's specifically going wrong and work
> out how else it can be improved, rather than insisting that this could
> never be part of a desktop file. Labelling options with some kind of
> priority is compromise we live with in various places.
>
>
> I am all for understanding the problem and its context in order to find an
> appropriate solution.  It is based on my present understanding of the
> context that I persist in asserting that desktop files should not express
> policy.  I don't see anything in the specific problem presented that
> challenges that position as far as I am concerned, and I am having trouble
> imagining what sort of thing would.  In short: although firm, my position
> is analytical, not dogmatic.
>
>
> John
>
>
> ------------------------------
>
> Email Disclaimer: www.stjude.org/emaildisclaimer
> Consultation Disclaimer: www.stjude.org/consultationdisclaimer
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/xdg
>


-- 
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/xdg/attachments/20210217/e60dda26/attachment.htm>