New `MimeType` fields in .desktop

[shirish शिरीष]

At bottom :-

On 16/02/2021, Jehan Pagès <jehan.marmottard at gmail.com> wrote:
> Hello all!
>
> I would have a small proposition about the mime type handling in desktop
> spec.
> I perfectly understand why the format does not specify any priority
> whatsoever so far (some software might want to put themselves priority for
> everything).
>
>> There should be no priority for MIME Types in this field, or any form of
> priority in the desktop file. Priority for applications is handled external
> to the .desktop files. [from Desktop Entry Specification ]
>
> Yet I believe that some trust is also needed if we want better
> format-software associations' default behavior. Actually I would be
> interested in some priority-related fields for the exact opposite as what
> the spec is scared of: responsible devs will be able to tell (through their
> desktop file) when a software should not overload existing mimetype
> priority settings. In my case, I would do this for GIMP.
>
> Typically someone reported an issue about GIMP taking over handling of
> image types it supports every time it is installed/updated. So for instance
> JPEG images were not displayed by default with a simple image viewer
> anymore, but in GIMP.
>
> When it is perfectly reasonable for its native image format (XCF), and
> possibly for other similar format when another software hasn't set it as
> its native format (typically PSD or ORA, you usually want to edit them not
> just show them, so if you don't have say Photoshop, you'd look for software
> with similar intent, such as GIMP), it is obviously not ideal for common
> finale image formats (JPEG, PNG, etc.) which you'd want to see in a viewer.
>
> I do remember having had similar issues over the years for various format
> associations with various software, forcing me to override settings
> manually after. Worst case I encountered was when some software would even
> take over handling the native format of another software (even though this
> other software is installed as well)!
>
> It's still important that GIMP can advertize supporting all these formats,
> for instance to be proposed in the recommended alternative list of software
> (for when you want to edit the image files); or also when no other software
> support them (many old image formats and often some very recent image
> formats are nearly only supported by GIMP among Free Software), GIMP can
> serve as nice display fallback. Yet it'd be nice if we could make a
> difference.
>
> So I would propose 2 fields with the same syntax as MimeType field:
>
> - NativeMimeType: the list of mime types which can be considered as the
> native formats of the software. For instance for GIMP:
>
> NativeMimeType=image/x-xcf;image/x-compressed-xcf
>
> - IntentMimeType: the list of supported mime types which can be considered
> of the same nature as the native mime types, the same "intent" files.
> Typically GIMP is an editing software, and XCF is an image edition project
> file. Same are the OpenRaster format (standard exchange format for such
> programs) or native formats of other similar software (e.g. PSD from
> Photoshop). So GIMP could have:
>
> IntentMimeType=image/x-psd;image/openraster
>
> To keep compatibility with older systems, all these formats should **also**
> be in the MimeType field.
>
> What it means for a system/distribution when you install/update a software
> with a NativeMimeType field: the new software **should** become the new
> default association.
>
> For IntentMimeType, more software are expected to have these.
> NativeMimeType is obviously a stronger association.
>
> As for MimeType, unless a software happens to be the only one handling a
> given format (hence it's an ok fallback), the system should probably never
> switch the defaults.
>
> Of course, if a format-software association was set manually, it would be
> best to never let automatic re-association with another software happen.
>
> What do you think?
>
> Thanks!
>
> Jehan
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Liberapay: https://liberapay.com/ZeMarmot/
> Patreon: https://patreon.com/zemarmot
> Tipeee: https://www.tipeee.com/zemarmot
>

Hi all,
I read quite a bit of the fascinating thread. As a user I have often
had to fix the same at my end and at times had to re-fix it again. For
me it's the 'mkv' and related media file types. Now I have different
applications which are for different things, For e.g. mpv is
exclusively the player (followed at times by vlc) for playing the
content. Mediainfo to have technical knowledge/bits about the content.
ffmpeg for doing some basic stuff (extracting subtitles or adding
subtitles etc.) to the content, re-encoding into smaller resolution
etc etc.

Sadly, none of the solutions as of date tell me if I hover or even go
into properties of a mkv file which application does what. I do know
this is perhaps a bit outside the discussion having, but does anybody
have any ideas? At the very least, it should make the user more aware
of what he can do with particular applications perhaps.

One way is to perhaps have a database so if I ask in a way that the
system understands which are the editors which can be used to
manipulate or edit mkv files, it should give me a list available from
debian database. I do know that apt, aptitude etc. do try to do
something on those lines but it has many shortcomings. And as somebody
else mentioned, don't think the solution would be done tomorrow but at
least sometime in future.

-- 
          Regards,
          Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com

E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C