<div dir="ltr"><div dir="ltr">Hi!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021 at 1:30 PM Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk" target="_blank">thomas@kluyver.me.uk</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"><u></u><div><div>On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:<br></div><blockquote type="cite" id="m_-7353725119196589282gmail-m_8073237350921098477qt"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">But that does not imply that some applications should be able to claim to be more equal than others
 with respect to particular file types.<br></div></blockquote><div><br></div><div>I think Jehan's idea is that applications should be able to claim to be *less* equal than others for a given mimetype, i.e. that GIMP could declare 'I can open JPEGs, but you should probably use something else by default'. Obviously, if the user explicitly set GIMP as the default handler for image/jpeg, it would override this priority.<br></div></div></blockquote><div><br></div><div>Yes! Finally someone who reads emails before answering. :-)</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"><div><div>Distinguishing things like 'native' and 'equivalent intent' filetypes seems tempting, but I suspect it would end up with a lot of awkward grey areas. If this is a problem worth solving, I'd be more inclined to make a numeric priority scale, something like the shared-mime-info database uses for assigning mimetypes to files (which allows e.g. ODT files to be recognised as ODT rather than general zip files).<br></div></div></blockquote><div><br></div><div>It's an interesting idea, but wouldn't it be very hard to tell? Like if someone asked me how much of PSD is supported on GIMP (on a scale, say from 0 to 10), I would have no idea where we stand. We do have support, and we try to improve it regularly. We also accept patches with arms wide open. But how much of it is supported? No idea.</div><div>And I'm pretty sure that unless some type were your native format (either because you created it, or decided to make it your own native format too), most applications out there would not be able to say exactly where they are on a scale, since their focus is elsewhere (creating the best application supported by its own format). This means that what most devs would set for their support of many formats would be very approximate. Thus if it's later used to determine which should be the best defaults, it would not be actually fair.<br></div><div><br></div><div>What we can say is that PSD is a format with a somewhat similar intent (raster image editing work-in-progress format) and that we have some ok support of it.</div><div><br></div><div>The other risky issue of comparing support with a scale is that some software may actually have a not-perfect support yet still be completely intended for a format. Typically if not mistaken, LibreOffice, OpenOffice, Calligra all have OpenDocument as their native formats. Yet maybe one of them misses the support of specific features (I have no idea if true, but would not be impossible). Therefore say this one application sets a support at 9 whereas the other would have support at 10. It would not be fair because their intent matters most here IMO. If they all intend to support ODT as native format, it is very likely that if someone installs any of them, they are still fit as good default ODT editor.</div><div><br></div><div>This is the reason why I went with semantic fields rather than scale-based fields. I think that intent matters most here. "What is your program actually for?"</div><div><br></div><div>Nevertheless if we wanted to have some types of scaling (I would say, additionally to the intent-based semantics), I would go for approximate/named ones, not numeric based for the reasons cited above. Like "Perfect" (you can open any file), "Very Good", "Good", "Average" and so on. Then we could probably situate GIMP's PSD support there (and even so, not so sure, I'd hesitate between Average and Good nowadays; even this, it depends on people anyway; for many usage, our support is good, but for people needing specific features which GIMP doesn't provide, they would consider our PSD support as bad. As I said, situating non-native support on a scale is a lot more difficult that one would imagine).<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"><div><div></div><div><br></div><div>Another approach to the stability issue (e.g. GIMP 'taking over' the JPEG mimetype) is for the desktop to fix it: if you open a JPEG file and there isn't already a default application for that, store whatever it uses as the default application, so it won't change unless the user manually changes the association or uninstalls that application. I think that could be done without changing any specs.<br></div></div></blockquote><div><br></div><div>Yeah the default application on same level of intent is a difficult question, which was why I was not really focusing on it. I'm not sure but it doesn't look like all distributions/desktop do the same thing currently. It would seem that some at least would just set the last installed software as default. This is definitely wrong often, but I can see also how it can make sense to some. I don't actually think there is a single right answer to this problem unfortunately.</div><div><br></div><div>IMO adding some semantics on the file association intent is a good compromise (hence my proposal), but we may not have better hints than these. You may have several applications installed with the same native format. Then which should be the default? Impossible to answer (only the user can). You may have no application using a given format as native, but several applications with similar intent and supporting it, which should be used? And finally you may have no application with native or intent, but several applications with support, which should be used? All these questions cannot really be answered IMO.<br></div><div><br></div><div>With this in mind, it might not be necessary to update the specs with stability advices. Or if we do, it would only be to make an arbitrary choice for the sole purpose of having at least a common behavior across distributions and desktops (which is nice too) but I don't think we can actually say for sure this is a better choice. I can definitely see pros and cons to both logics (keeping stability or not when no user-set preferences were set).<br></div><div><br></div><div>Jehan<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"><div><div></div><div><br></div><div>Thomas<br></div></div>_______________________________________________<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">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>