GNOME Bugzilla – Bug 510319
tracker bug for x-content/* support
Last modified: 2008-06-10 14:58:08 UTC
This bug is for tracking bugs against components to use the new x-content/* machinery now available in Nautilus. Please see http://svn.gnome.org/viewvc/nautilus/trunk/data/nautilus.xml.in?revision=13616&view=markup for the currently defined x-content/* types. See http://people.freedesktop.org/~david/nautilus-fmp-5.png http://people.freedesktop.org/~david/nautilus-fmp-4.png http://people.freedesktop.org/~david/nautilus-utopia-5.png http://people.freedesktop.org/~david/nautilus-utopia-3.png for the properties dialog; and http://people.freedesktop.org/~david/nautilus-utopia-4.png for the prompt when "Ask what to do" is selected for a given type; and http://people.freedesktop.org/~david/nautilus-x-content-open-with.png http://people.freedesktop.org/~david/nautilus-x-content-cluebar-1.png http://people.freedesktop.org/~david/nautilus-cluebar-musicplayer.png for integration elsewhere in Nautilus. Support for this was committed to Nautilus on Thu Jan 17 2007. Basically, the way it works, is that one can declare that an application is capable of handling the x-content/FOO type by including x-content/FOO in the MimeTypes key of a .desktop file (this may, or may not, be the same desktop file as the one appearing in menus). When launched, a single positional parameter is passed, the URI (in case %u is used) or file name (in case %f is used) will be available for the desktop file. Standardizing x-content/* as a freedesktop.org specification (maybe part of shared mime info spec) is planned and is expected to be finalized before GNOME 2.24. The way it works may change (although it is expected it won't).
Btw, I figure I should explain in more detail what x-content/* is about. So, x-content/* types is a way to classify _media_ similar to how MIME types is used classify _files_. In fact, parts of the machinery for MIME types is used to make this work. There are also other bits used to allow the user to 1) always choose what to do when media of a given x-content/* type is inserted; 2) choose to open a nautilus window instead; and 3) ignore it. The reason this work was done was to replace the rather unfriendly way this was done in gnome-volume-manager / gnome-volume-properties http://wshlab2.ee.kuas.edu.tw/~yurenju/albums/screenshot/Screenshot_Drives_and_Media_Preferences.png See bug 509823 for the request to remove this functionality from g-v-m. The classification of media is right now hard-coded into Nautilus proper [1]. For 2.24 the plan is to move this into a function on the GMount interface in gio. The actual code for probing will then move to the volume monitor backends (UNIX and hal currently) as well as some shared base code. (Also, there are (currently vague) plans to make the sniffing mechanism extensible so e.g. 1. an app can define a new x-content/* type by dropping a file in /usr/share/mime/packages/. 2. the app can provide code to help the gio/gvfs backends to match a mount with the mount type How this is going to work is yet undefined. It's pending discussion on xdg-list.) Hope this clarifies. Feel free to ask questions if more detail is needed. Thanks. [1] : Specifically see the function _g_mount_guess_content_type() http://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-autorun.c?revision=13616&view=markup
Btw, we probably need an extension to the desktop entry spec so I can write a desktop file like this example.desktop: Name=Some CD Burner Application Exec=some-cd-burner-application %b MimeTypes=x-content-blank-cd; where %b would mean the block device. So e.g. /dev/sr0 or /dev/sr1 would be passed depending on what drive I put the disc into. Need to get that into http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
David, all the dependencies of this bug seem to have been fixed. Can we close this too?
Yup, I'm closing this bug for now.