handling optional MimeTypes in a Desktop Entry
hadess at hadess.net
Fri May 2 10:42:53 PDT 2014
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.
More information about the xdg