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 530055 - regression: media-handling applications need %d, %m, %h variables that gnome-volume-manager used to provide
regression: media-handling applications need %d, %m, %h variables that gnome-...
Status: RESOLVED WONTFIX
Product: gnome-settings-daemon
Classification: Core
Component: automount
2.22.x
Other All
: Normal major
: ---
Assigned To: gnome-settings-daemon-maint
gnome-settings-daemon-maint
: 607716 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-04-26 12:21 UTC by Sam Morris
Modified: 2012-09-21 12:07 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Sam Morris 2008-04-26 12:21:55 UTC
gnome-volume-manager used to provide the programs it launched with the following three variables that they could use in their command lines:

 %d - device node: /dev/scd0
 %h - HAL UDI - /org/freedesktop/Hal/devices/volume_label_PLANETES_V3D1
 %m - mount point - /media/cdrom0

There appears to be no way to do this with nautilus; it tries to use an application's .desktop file's Exec key, but the three above do not really fit into this use.

One way to fix this would be to introduce a new desktop entry key: 'X-Nautilus-Media-Exec', which would allow applications to specify a second command line that can take the above parameters.

For example: serpentine, an audio CD burner is launched like this: 'serpentine -o file1.mp3 file2.mpe file3.mp3'. That tells it to create a new playlist containing those files. Thus, its 'Exec' value is 'serpentine -o %U'.

However, when launched from gnome-volume-manager, it needs to be launched like this: 'serpentine --device /dev/scd0'. This was easy with gnome-volume-manager: it put 'serpentine --device %d' into gnome-volume-manger's preferences. However with nautilus, it would be launched like: 'serpentine -o file:///media/dvdrw' which is totally wrong, and there seems to be no way to get it launched with the correct parameters.
Comment 1 Sam Morris 2008-04-26 12:38:38 UTC
Another example: sound-juicer must be launched with either 'sound-juicer' or 'sound-juicer --device /dev/sdc0'. If just 'sound-juicer' is in the .desktop file then it won't know which CD drive to rip audio from when the user inserts a CD.
Comment 2 Christian Neumair 2008-04-27 09:13:11 UTC
I agree. This is a clear regression.

Using X-Nautilus-* keys is not very cross-desktop friendly, though.
We should instead spec this behavior in a desktop-neutral way

Two years ago, I actually proposed a desktop file spec for media handling:

http://mail.gnome.org/archives/gnome-hackers/2006-October/msg00002.html

I did not receive any feedback, though. David: Maybe you could look through the spec and give some comments?
Comment 3 David Zeuthen (not reading bugmail) 2008-04-27 15:18:32 UTC
This can hardly be a regression because it's all new code. But it's true g-v-m supported that and in some way you could call it a regression.

Anyway, one point is this: Now that we have a real VFS system (including backends for audio cd's and digital cameras) there is no longer any need for passing %d or %h. It's much cleaner to just port these applications to use gio (and using gio, the application can find the UNIX device file or HAL udi if that's what it needs, e.g. sound-juicer).

If you insist on not fixing applications (and some people do), my view is that the way to fix this is a way to get %d into the desktop file specification. That would certainly be useful as a general thing to have. Or just use %f and then a FUSE POSIX path the to gio mounts for cdda:// and gphoto2:// will be passed (works for any POSIX application). 

(on a related matter of %u vs %f, see bug 528670)

Either way, I'm not sure it matters much today (with many apps currently not using gio) as this is a rather fringe use case.

> Maybe you could look through the spec and give some comments?

Isn't this already solved by the new x-content/* mechanism? The multiple Exec key problem is solved by just having multiple desktop files which is what you need anyway to get the Name and Icon right too. (see bug 510319 for the overview and also bug 510325 comment 5 for details)

(note that, as discussed with Alex earlier, the x-content/* machinery still needs to be proposed on fd.o so some changes might happen there)

[1] : and don't bother with %h, HAL is going to get replaced by HAL 2.0 aka DeviceKit over the next few years anyways
Comment 4 David Zeuthen (not reading bugmail) 2008-04-27 15:35:41 UTC
(In reply to comment #3)
> Either way, I'm not sure it matters much today (with many apps currently not
> using gio) as this is a rather fringe use case.

I should probably explain what I mean by this. The point is that it's fine to use 'Exec=sound-juicer' for x-content/audio-cdda. This works fine because sound-juicer detects audio cd's automatically anyway when starting up and -d isn't passed. E.g. there is no need to pass it the underlying device file for the optical drive / audio disc.

Hope this clarifies.

Comment 5 Christian Neumair 2008-04-27 16:24:00 UTC
re comment #3 and #4:

> (...) using gio, the application can find the UNIX device file or HAL udi if
that's what it needs, e.g. sound-juicer.
> (...) it's fine to use 'Exec=sound-juicer' (...). This works fine because sound-juicer detects audio cd's automatically anyway when starting up (...).

I do not understand the role of gio - how is the target drive determined for multiple-drive configurations?

Assuming you have two CD drives, a disk is in drive A and you insert another disk in drive B. Assuming autorun is enabled, sound-juicer will be run. How can sound-juicer then use gio to determine that it was launched due to an event coming from drive B?
Comment 6 David Zeuthen (not reading bugmail) 2008-04-27 16:33:13 UTC
(In reply to comment #5)
> re comment #3 and #4:
> 
> > (...) using gio, the application can find the UNIX device file or HAL udi if
> that's what it needs, e.g. sound-juicer.
> > (...) it's fine to use 'Exec=sound-juicer' (...). This works fine because sound-juicer detects audio cd's automatically anyway when starting up (...).
> 
> I do not understand the role of gio - how is the target drive determined for
> multiple-drive configurations?
> 
> Assuming you have two CD drives, a disk is in drive A and you insert another
> disk in drive B. Assuming autorun is enabled, sound-juicer will be run. How can
> sound-juicer then use gio to determine that it was launched due to an event
> coming from drive B?

In this case, it of course that won't work. But it's not really a big problem as a) most users won't have such setups (two audio discs inserted at the same time); and b) there's UI in the app to choose the right disc. It's not _perfect_ but it's certainly _good enough_ for unmodified apps.

The right solution, I think, includes either extending the desktop entry spec and gio to support %d or making the application properly interpret %u (e.g. cdda://sr0/) and get the UNIX device file (e.g. /dev/sr0) that way. We should do both IMO.
Comment 7 Sam Morris 2008-04-28 19:06:35 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Either way, I'm not sure it matters much today (with many apps currently not
> > using gio) as this is a rather fringe use case.
> 
> I should probably explain what I mean by this. The point is that it's fine to
> use 'Exec=sound-juicer' for x-content/audio-cdda. This works fine because
> sound-juicer detects audio cd's automatically anyway when starting up and -d
> isn't passed. E.g. there is no need to pass it the underlying device file for
> the optical drive / audio disc.

This does not work at all! See bug #530423.

Same for Rhythmbox if it is the audio CD handler--it opens up, but it doesn't have the audio CD selected automatically and it doesn't start to play.
Comment 8 David Zeuthen (not reading bugmail) 2008-04-28 19:44:26 UTC
(In reply to comment #7)
> This does not work at all! See bug #530423.
> 
> Same for Rhythmbox if it is the audio CD handler--it opens up, but it doesn't
> have the audio CD selected automatically and it doesn't start to play.

Sounds to me like these are bugs in the apps. Or more likely gstreamer problem. FWIW, I can reproduce this, I can't even get sound-juicer working even when the gvfs cdda backend isn't running. [1] 

Either way, the gvfs cdda backend doesn't open the device exclusively (libcdio doesn't do that because it's just not necessary; multiple openers work just fine) so it will never ever conflict with other apps. In fact, after resolving the issue described in [1] I can happily run the gvfs cdda backend and rhythmbox and/or sound-juicer at the same time

Anyway, I'm not sure why you think it's necessary to bring up such issues on this bug. All that the x-content/* mechanism provides, is a way to launch applications based on what's on the media.

Hope this helps.

[1] : But wait.. doing 'sudo chown davidz:davidz /dev/sr0' fixes it! So there's probably an access check that ignores the ACL that I've have on the device already. And the ACL is more than enough otherwise the gvfs cdda wouldn't work. All this is terribly distro specific but I thought I'd bring it up anyway.
Comment 9 Sam Morris 2008-04-28 19:53:36 UTC
Well I brought it up because it's a clear example of why %d or %m or %h must be passed to the applications that are launched. :)
Comment 10 Christian Neumair 2008-05-17 10:18:03 UTC
(in reply to comment #6):

> (For multiple volumes), (automatic disk detection) of course (...) won't work. But it's not really a big problem
> as a) most users won't have such setups (two audio discs inserted at the same
> time); and b) there's UI in the app to choose the right disc. It's not
> _perfect_ but it's certainly _good enough_ for unmodified apps.

In your last informal DeviceKit email [1] you pointed out:

“A device is identified by a) the native OS-specific path (on Linux a sysfs path); b) an optional UNIX device file; and c) key/value pairs describing the
device.”

So what's the point of not giving the invoked application a chance of identifying the launched device?

We just need “a native OS-specific path“, assuming this feature is available on all target platforms. We do not lose anything, and app authors and users just win.

If you are against the addition of new parameters, we can also add an environment variable “AUTORUN_DEVICE” that can be read out by the launched applications.


[1] http://lists.freedesktop.org/archives/hal/2008-May/011560.html
Comment 11 David Zeuthen (not reading bugmail) 2008-05-18 16:19:09 UTC
(In reply to comment #10)
> (in reply to comment #6):
> 
> > (For multiple volumes), (automatic disk detection) of course (...) won't work. But it's not really a big problem
> > as a) most users won't have such setups (two audio discs inserted at the same
> > time); and b) there's UI in the app to choose the right disc. It's not
> > _perfect_ but it's certainly _good enough_ for unmodified apps.
> 
> In your last informal DeviceKit email [1] you pointed out:
> 
> “A device is identified by a) the native OS-specific path (on Linux a sysfs
> path); b) an optional UNIX device file; and c) key/value pairs describing the
> device.”
> 
> So what's the point of not giving the invoked application a chance of
> identifying the launched device?
> 
> We just need “a native OS-specific path“, assuming this feature is
> available on all target platforms. We do not lose anything, and app authors and
> users just win.
> 
> If you are against the addition of new parameters, we can also add an
> environment variable “AUTORUN_DEVICE” that can be read out by the launched
> applications.

I'm fine with supporting %d (for passing the UNIX special device file, e.g. /dev/sdb1 for block devices and /dev/bus/usb/001/001 for usb devices) if it's in the desktop entry spec. 

So I'm also fine with having e.g. %e for the native OS path of the device though that needs to be properly defined; right now it's just a DeviceKit concept and DeviceKit isn't released yet.

My point, I think, was that I don't think it's particular useful anyway; applications should be ported to use gio. But sure, for some apps that will never happen.

So I'd start with trying to get %d into the desktop entry spec; then add support to gio for it. What do you think about that?

Comment 12 Christian Neumair 2008-05-18 23:11:17 UTC
> So I'd start with trying to get %d into the desktop entry spec; then add
support to gio for it. What do you think about that?

That is a very good and pragmatic idea :). It would resolve all the concerns.

Device nodes fit with the traditional UNIX semantics, and they are desktop and HAL agnostic. Applications should always be able to conclude back on the HAL device from the device node.
Comment 13 Shahar Or 2009-04-06 11:14:09 UTC
Dear interested parties,

The last comment was made by Christian almost 11 months ago.

In the latest Ubuntu release, this is still not fixed. A user puts in an audio CD, clicks OK and Rhythmbox launches and doesn't start playback.

Please take appropriate action regarding this issue.

Many blessings.
Comment 14 Sam Morris 2009-09-28 13:45:32 UTC
Poke?
Comment 15 A. Walton 2010-01-22 03:04:07 UTC
*** Bug 607716 has been marked as a duplicate of this bug. ***
Comment 16 Bastien Nocera 2012-09-21 12:07:00 UTC
Rhythmbox, sound-juicer, Totem, etc. can handle URIs being passed to them. It's up to the application to handle this. Expecting changes to both gnome-settings-daemon, the desktop file specification and the desktop files to handle things that can be achieved programmatically (finding the device file associated with a mount point) isn't reasonable.

Closing.