handling optional MimeTypes in a Desktop Entry

[François Cami]

Hi all,

I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html
and haven't found an answer to my problem, so here goes:

If I were to write an application able to open one or zero MimeType
by default, and optionally-installed plugins providing support for
more MimeType, should I:
* specify all possible MimeTypes in a single Desktop Entry and hope
for the best (hope not);
* ship a Desktop Entry with the application and with each plugin, with
the same "Name" key, so that the list of MimeTypes supported by the
application gets somehow merged by the Desktop Entry implementation -
though unless I'm mistaken this is not in the specification;
* ship a Desktop Entry with the application and specify to
distributions that it should be altered each time a plugin is
installed or removed, in effect treating the Desktop Entry as a
configuration file?

Any input greatly appreciated.

François

[Rex Dieter]

Post by François Cami
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html
If I were to write an application able to open one or zero MimeType
by default, and optionally-installed plugins providing support for

...

Post by François Cami
* ship a Desktop Entry with the application and with each plugin, with
the same "Name" key, so that the list of MimeTypes supported by the
application gets somehow merged by the Desktop Entry implementation -
though unless I'm mistaken this is not in the specification;

+1 to this option (several kde applications do it this way now, including
okular for example)

-- rex

[Ryan Lortie]

hi,

Post by François Cami
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html

I'm not sure any of these options will really work.

In the simple case of applications with plugins one of these options
might be acceptable, but consider the case that we have something like
Totem using GStreamer. When I install a GStreamer plugin, how should it
know about Totem existing in order to update its list?

The only thing I can think of is that we have some mime type to mean
"all of the types of things supported by GStreamer" (where GStreamer
could also be the name of an individual application, in the case of
direct plugins). It might make sense to also say "all of the _audio_
file types supported by GStreamer" as well.

I'm not really sure what this would look like, and I'm also not sure if
I would be in favour of the final result. This is a tough problem and
I'm not sure that any solution is palatable.

Cheers

[Bastien Nocera]

Post by Ryan Lortie
hi,

Post by François Cami
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html

I'm not sure any of these options will really work.
In the simple case of applications with plugins one of these options
might be acceptable, but consider the case that we have something like
Totem using GStreamer. When I install a GStreamer plugin, how should it
know about Totem existing in order to update its list?
The only thing I can think of is that we have some mime type to mean
"all of the types of things supported by GStreamer" (where GStreamer
could also be the name of an individual application, in the case of
direct plugins). It might make sense to also say "all of the _audio_
file types supported by GStreamer" as well.
I'm not really sure what this would look like, and I'm also not sure if
I would be in favour of the final result. This is a tough problem and
I'm not sure that any solution is palatable.

For the GStreamer case, I should add that:
- GStreamer doesn't really "support" mime-types. At best, you would know
that you have a plugin to handle the container type (AVI, MPEG-4, MKV).
- Using GStreamer's automatic codec installers requires _all_ the
possibly supported types to be listed in the desktop file.

Cheers

[Ted Gould]

Post by Bastien Nocera

Post by Ryan Lortie

Post by François Cami
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html

I'm not sure any of these options will really work.
In the simple case of applications with plugins one of these options
might be acceptable, but consider the case that we have something like
Totem using GStreamer. When I install a GStreamer plugin, how should it
know about Totem existing in order to update its list?
The only thing I can think of is that we have some mime type to mean
"all of the types of things supported by GStreamer" (where GStreamer
could also be the name of an individual application, in the case of
direct plugins). It might make sense to also say "all of the _audio_
file types supported by GStreamer" as well.
I'm not really sure what this would look like, and I'm also not sure if
I would be in favour of the final result. This is a tough problem and
I'm not sure that any solution is palatable.

- GStreamer doesn't really "support" mime-types. At best, you would know
that you have a plugin to handle the container type (AVI, MPEG-4, MKV).
- Using GStreamer's automatic codec installers requires _all_ the
possibly supported types to be listed in the desktop file.

We're not using desktop files for this on Ubuntu, but content hub
registrations. What we decided for the GStreamer case is to have a key
that was "I use GStreamer" so then the hub could be smart enough to look
at GStreamer and turn those into types that can be supported. Allows for
support of proprietary protocols on devices that have licenses (and
plugins) that support them.

Ted

[Bastien Nocera]

Post by Ted Gould

Post by Bastien Nocera

Post by Ryan Lortie

Post by François Cami
I've read the Desktop Entry Specification at
http://standards.freedesktop.org/desktop-entry-spec/latest/index.html

I'm not sure any of these options will really work.
In the simple case of applications with plugins one of these options
might be acceptable, but consider the case that we have something like
Totem using GStreamer. When I install a GStreamer plugin, how should it
know about Totem existing in order to update its list?
The only thing I can think of is that we have some mime type to mean
"all of the types of things supported by GStreamer" (where GStreamer
could also be the name of an individual application, in the case of
direct plugins). It might make sense to also say "all of the _audio_
file types supported by GStreamer" as well.
I'm not really sure what this would look like, and I'm also not sure if
I would be in favour of the final result. This is a tough problem and
I'm not sure that any solution is palatable.

- GStreamer doesn't really "support" mime-types. At best, you would know
that you have a plugin to handle the container type (AVI, MPEG-4, MKV).
- Using GStreamer's automatic codec installers requires _all_ the
possibly supported types to be listed in the desktop file.

We're not using desktop files for this on Ubuntu, but content hub
registrations. What we decided for the GStreamer case is to have a key
that was "I use GStreamer" so then the hub could be smart enough to
look at GStreamer and turn those into types that can be supported.
Allows for support of proprietary protocols on devices that have
licenses (and plugins) that support them.

Again, that's a static case. That doesn't allow for searching for
3rd-party plugins that could implement playing such codecs. This is
probably fine if you don't have support for adding new plugins, or if
the list of plugins is finite.