GNOME Bugzilla – Bug 510325
x-content/* support
Last modified: 2008-04-24 15:33:25 UTC
Please include support for the new x-content/* machinery available in Nautilus. Specifically, adding support for the types x-content/image-dcf x-content/image-picturecd would make sense. Please see bug 510319 for details about x-content/*. Thanks.
I should also add that I'm currently working on a gphoto2 backend for gvfs. So when that one lands (aiming for 2.22 actually) you can use this to get the photos from the media; the only difference is that the URI would be gphoto2://usb-4-1/dcim/100eos5d/_mg_0348.jpg instead of file:///media/EOS_DIGITAL/dcim/100eos5d/_mg_0348.jpg Of course this would mean that you'd need to use gio instead of what you're using now but you probably want that anyway. If you do that and your only use of gphoto2 is to download photos (e.g. no camera remote control) you should be able to completely remove gphoto2 from f-spor proper.
*** Bug 516383 has been marked as a duplicate of this bug. ***
Stephane, can we have MimeType=x-content/image-dcf,x-content/image-picturecd added to the f-spot .desktop file? Comment #1 is a future task, just adding the x-content would make f-spot show up in the new default application handler in nautilus 2.22 which probably many users (all those who started f-spot import using gnome-volume-manager before) want.
David, I totally understand the need for x-content/* support, but still don't know how to implement this correctly for f-spot. Hope you'll be able to enlighten me on how other projects are dealing with the same problems: * g-v-m was able to launch commands with some flags, like "banshee --play --audio-cd %d". How is this supposed to work with Exec ? * g-v-m allowed us to lauch a special script on import "f-spot-import %h", responsible of getting the mount point from hal for mass-storage camera or a gphoto2: path for the others. How can I launch a special command with the Exec machinery ? * what about the %d, %s, %h flags handled by g-v-m and not by Exec ? As I see the thing, there's 2 options: * the ugly one: create a f-spot-import.desktop file, Exec'ing f-spot-import %u * the long and hard one: import on Exec "f-spot %u". And I'm not even sure I'd like having import as the default action on command-line invocation...
(In reply to comment #4) > David, > > I totally understand the need for x-content/* support, but still don't know how > to implement this correctly for f-spot. Hope you'll be able to enlighten me on > how other projects are dealing with the same problems: > > * g-v-m was able to launch commands with some flags, like "banshee --play > --audio-cd %d". How is this supposed to work with Exec ? In general you just want the URI using %u; from the URI you can use gio to get the device file (through g_volume_get_identifier()). And ideally apps should use the gio/gvfs file system drivers to access the device (e.g. cdda:// for audio discs and gphoto2:// for PTP and MTP devices). Which I do appreciate is some work. But in the long run it will simplify your application and making sharing the device with e.g. Nautilus / other apps work a lot better. But see below for what do to in the interim. > * g-v-m allowed us to lauch a special script on import "f-spot-import %h", > responsible of getting the mount point from hal for mass-storage camera or a > gphoto2: path for the others. How can I launch a special command with the Exec > machinery ? See below. > * what about the %d, %s, %h flags handled by g-v-m and not by Exec ? > > As I see the thing, there's 2 options: > * the ugly one: create a f-spot-import.desktop file, Exec'ing f-spot-import %u I'm not sure what's so ugly about this? It's probably what you want in general since you can - tweak the name to e.g. "F-Spot photo importer" - tweak the icon (the one that appaears in Nautilus' preference dialog in the Media tab) - start f-sport with --import if you want to avoid a wrapper script. You'd also want to use NoDisplay in that desktop file. For the interim e.g. where the app don't use gio natively, said import wrapper could take the URI (e.g. cdda:// or gphoto2://) and use g_volume_get_identifier() to get the device file. It would also unmount the gvfs file system for things like gphoto2:// where the USB device is claimed by the gvfs backend (USB only supports one opener). > * the long and hard one: import on Exec "f-spot %u". And I'm not even sure I'd > like having import as the default action on command-line invocation... I'd just use a dedicated desktop file like mentioned above. It's perfectly fine to do so.
Created attachment 108165 [details] [review] proposed patch Does this patch makes sense to you ? I currently have no way to test it, as I'm still running nautilus 2.20
works fine on opensuse11. committed as r3842.