Re: DynamicMimeTypes
On Wed, 2007-08-15 at 21:34 +0100, Alex Jones wrote: On Wed, 2007-08-15 at 14:17 -0500, Shaun McCance wrote: On Tue, 2007-08-14 at 23:18 +0100, Alex Jones wrote: Hi List Applications like Rhythmbox and Totem have content handling capabilities that are dependent on GStreamer. Currently, they have to hardcode a list of MIME types in their Desktop Entries, which sucks a bit. So how about we try something like I've sketched up in the attached diagram. Rhythmbox can then say that it can handle all file types given by the registered org.gstreamer.Audio handler, which will return something like: audio/mpeg audio/x-vorbis+ogg audio/x-flac ... And these types can be munged in with the rest of the types listed in the Desktop Entry. Also if someone else could think of some better terminology, that would be super. There are other cases where we can't just query a library like GStreamer. Take, for example, File Roller. It can handle *LOTS* of archives formats, but only if you have the command line tools for those formats installed. What if we just added a MimeTypeExec field which gives a command to run. This command should give a list of MIME types that are actually supported. Then file-roller.desktop could have this: MimeTypeExec=/usr/libexec/file-roller-mime-types And Ryhthmbox and Totem and such could call some command supplied by GStreamer. The only difference between this and what I suggested is that you are giving an explicit path to a script (what I was calling a handler) to be run. It's the same idea. OK, I guess I don't quite understand where the handler fits in. What I've seen in the past are proposals involving MIME groups, which could be specified in something like desktop entry files. These proposals always assumed that a plug-in will also install some sort of data to add a MIME type to a group. This, to me, is a weakness, because there are things like File Roller which just depend on command line programs. And I think there's very little chance we'll ever see programs like rar or zoo shipping with a data file to tell the desktop that File Roller can also handle their formats. But a custom script shipped with File Roller could easily check for the existence of these programs. Could you explain in a bit more detail how your handlers work? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DynamicMimeTypes
On Thu, 2007-08-16 at 10:04 -0500, Shaun McCance wrote: On Wed, 2007-08-15 at 21:34 +0100, Alex Jones wrote: The only difference between this and what I suggested is that you are giving an explicit path to a script (what I was calling a handler) to be run. It's the same idea. OK, I guess I don't quite understand where the handler fits in. What I've seen in the past are proposals involving MIME groups, which could be specified in something like desktop entry files. These proposals always assumed that a plug-in will also install some sort of data to add a MIME type to a group. This, to me, is a weakness, because there are things like File Roller which just depend on command line programs. And I think there's very little chance we'll ever see programs like rar or zoo shipping with a data file to tell the desktop that File Roller can also handle their formats. But a custom script shipped with File Roller could easily check for the existence of these programs. Could you explain in a bit more detail how your handlers work? Sure You could just install executables under /usr/lib/$handlers org.gstreamer.Audio org.gnome.FileRoller The former is installed by GStreamer and probes the GStreamer registry to figure out what kind of file types it can play (as was said earlier, this isn't that simple, but we can probably make a start with this method.) The latter is installed by File Roller and uses file roller's code to decide what formats it can handle by seeing what programs are installed and testing their capabilities. Applications like Banshee may want to install their own handler that itself calls org.gstreamer.Audio and org.helix-community.Audio (if it exists, or use its own code to figure out what the helix backend's capabilities are) I'm just suggesting that we standardise these script locations and names. We don't have to, I just thought it was nice. It's of little importance, though. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DynamicMimeTypes
On 15.08.2007 00:18, Alex Jones wrote: Applications like Rhythmbox and Totem have content handling capabilities that are dependent on GStreamer. Currently, they have to hardcode a list of MIME types in their Desktop Entries, which sucks a bit. So how about we try something like I've sketched up in the attached diagram. Rhythmbox can then say that it can handle all file types given by the registered org.gstreamer.Audio handler, which will return something like: audio/mpeg audio/x-vorbis+ogg audio/x-flac ... And these types can be munged in with the rest of the types listed in the Desktop Entry. One problem here is that GStreamer types != MIME types, even if they look pretty similar in many cases. You'll need some kind of mapping in the handler. Jens ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DynamicMimeTypes
On Tue, 2007-08-14 at 23:18 +0100, Alex Jones wrote: Hi List Applications like Rhythmbox and Totem have content handling capabilities that are dependent on GStreamer. Currently, they have to hardcode a list of MIME types in their Desktop Entries, which sucks a bit. So how about we try something like I've sketched up in the attached diagram. Rhythmbox can then say that it can handle all file types given by the registered org.gstreamer.Audio handler, which will return something like: audio/mpeg audio/x-vorbis+ogg audio/x-flac ... And these types can be munged in with the rest of the types listed in the Desktop Entry. Also if someone else could think of some better terminology, that would be super. There are other cases where we can't just query a library like GStreamer. Take, for example, File Roller. It can handle *LOTS* of archives formats, but only if you have the command line tools for those formats installed. What if we just added a MimeTypeExec field which gives a command to run. This command should give a list of MIME types that are actually supported. Then file-roller.desktop could have this: MimeTypeExec=/usr/libexec/file-roller-mime-types And Ryhthmbox and Totem and such could call some command supplied by GStreamer. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DynamicMimeTypes
On Wed, 2007-08-15 at 14:17 -0500, Shaun McCance wrote: On Tue, 2007-08-14 at 23:18 +0100, Alex Jones wrote: Hi List Applications like Rhythmbox and Totem have content handling capabilities that are dependent on GStreamer. Currently, they have to hardcode a list of MIME types in their Desktop Entries, which sucks a bit. So how about we try something like I've sketched up in the attached diagram. Rhythmbox can then say that it can handle all file types given by the registered org.gstreamer.Audio handler, which will return something like: audio/mpeg audio/x-vorbis+ogg audio/x-flac ... And these types can be munged in with the rest of the types listed in the Desktop Entry. Also if someone else could think of some better terminology, that would be super. There are other cases where we can't just query a library like GStreamer. Take, for example, File Roller. It can handle *LOTS* of archives formats, but only if you have the command line tools for those formats installed. What if we just added a MimeTypeExec field which gives a command to run. This command should give a list of MIME types that are actually supported. Then file-roller.desktop could have this: MimeTypeExec=/usr/libexec/file-roller-mime-types And Ryhthmbox and Totem and such could call some command supplied by GStreamer. The only difference between this and what I suggested is that you are giving an explicit path to a script (what I was calling a handler) to be run. It's the same idea. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
DynamicMimeTypes
Hi List Applications like Rhythmbox and Totem have content handling capabilities that are dependent on GStreamer. Currently, they have to hardcode a list of MIME types in their Desktop Entries, which sucks a bit. So how about we try something like I've sketched up in the attached diagram. Rhythmbox can then say that it can handle all file types given by the registered org.gstreamer.Audio handler, which will return something like: audio/mpeg audio/x-vorbis+ogg audio/x-flac ... And these types can be munged in with the rest of the types listed in the Desktop Entry. Also if someone else could think of some better terminology, that would be super. attachment: drawing.svg___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
