handling optional MimeTypes in a Desktop Entry

[Bastien Nocera]

On Fri, 2014-05-02 at 12:16 -0500, Ted Gould wrote:
> On Wed, 2014-04-30 at 11:38 +0200, Bastien Nocera wrote: 
> > On Wed, 2014-04-30 at 05:23 -0400, Ryan Lortie wrote:
> > > On Thu, Apr 24, 2014, at 13:50, François Cami wrote:
> > > > 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:
> > > 
> > > 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.
> 
> 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.