After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 510319 - tracker bug for x-content/* support
tracker bug for x-content/* support
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: general
unspecified
Other All
: Normal normal
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on: 510320 510321 510322 510323 510324 510325 510326 510329
Blocks:
 
 
Reported: 2008-01-18 04:33 UTC by David Zeuthen (not reading bugmail)
Modified: 2008-06-10 14:58 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description David Zeuthen (not reading bugmail) 2008-01-18 04:33:46 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).
Comment 1 David Zeuthen (not reading bugmail) 2008-01-18 05:16:13 UTC
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

Comment 2 David Zeuthen (not reading bugmail) 2008-01-18 05:26:32 UTC
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

Comment 3 Cosimo Cecchi 2008-06-07 12:38:03 UTC
David, all the dependencies of this bug seem to have been fixed. Can we close this too?
Comment 4 David Zeuthen (not reading bugmail) 2008-06-10 14:58:08 UTC
Yup, I'm closing this bug for now.