Bug 130866
Summary: | 'gthumb --import-photos' fails with mounted usb-storage device | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Tim Waugh <twaugh> |
Component: | gnome-volume-manager | Assignee: | John (J5) Palmieri <johnp> |
Status: | CLOSED RAWHIDE | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | davidz, jkeck, jspaleta |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-01 09:50:57 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 131347 | ||
Bug Blocks: | 123268 |
Description
Tim Waugh
2004-08-25 13:39:46 UTC
CCing dave on this. I'm guessing that it is best to for g-v-m not to mount the drive if import is selected. Dsrt on #gnome-devel is working on a dbus gphoto2 daemon which would allow multipule applications to access a device at once but I am not sure if we can get this in fc3 or not. It would also involve porting gthumb. Another option is to turn off auto importing alltogether for this release. forgot to cc david Uhm, maybe I'm missing something here. 1. If your camera is USB Mass Storage based g-v-m will think it's a disk and mount it. The presence of a DCIM tree will trigger the "You have new pictures" dialog that eventually takes you to 'gthumb --import-photos'. This will also be true for card readers with media that has a DCIM tree. I take this is what this bug is about. 2. If your camera is not based on USB Mass Storage and it got the hal capability 'camera' g-v-m also launch 'gthumb --import-photos' (Btw, I've written a hal callout that looks at /etc/hotplug/usb.usermap to use this) The bug is really upstream in g-v-m; it only gives *one* program for two *different* uses. Suggestion to write patch to g-v-m that enables the program to contain the HAL UDI (I need to write a few other small patches so I can do this and I'm confident it will be merged upstream) and write a wrapper for gthumb that does either 'gthumb /media/usbdisk1' or 'gthumb --import-photos' depending. Then the g-v-m capplet would contain 'launch-gthumb %h' and all would be well. Long term solution is more complicated, but this will at least make it work well for all digital cameras and card readers that are USB Storage + all digital cameras supported by gphoto2. Thoughts? Ok, I see. What I was missing was the discussion about unmounting and using gphoto2; I see now. This is not really feasible; we want to support card readers as well and only very few cameras support both USB Mass Storage and e.g. PTP as used by gphoto2. I got my patch merged upstream in g-v-m after nagging the maintainer; he even released 0.9.10. I've also built the callouts into hal so we properly detect gphoto2-based cameras. So as I see it only the following things need to be done 1. Add X-Red-Hat-Base to Categories in .desktop file (magicdev was in base) 2. Install the gvm-gthumb wrapper (there is one at http://lists.gnome.org/archives/utopia-list/2004-August/msg00100.html) 3. Tweak defaults to point to gvm-gthumb wrapper (might come up with a better name than gvm-gthumb) Re: Comment #3 Can you explain scenario 1 a little more. I get the dialog with cancel/import as the options. I select import and gthumb is just completely confused because it seems to be expecting a camera and not a mounted filesystem. Gthumb's import Photos dialog shows up... with a no camera detected icon.. a destination as /home/username and blank film and categorie fields. I try to hit import and I get a 'could not import photos: no camera detected' dialog. So it appears to me like hal and g-v-m are doing the clever thing and starting gthumb. but gthumb seems to be completely confused by the idea of mounted media with a dcim directory and looks to be expecting a camnera it can probe with libgphoto. /media/usbdrive/dcim exists and there are photos on the disk. Do i need to open up a bug against gphoto about this? What is the exaxct command that gets run to call gthumb in this case? does --import-photos take a location argument? How does gthumb know to look at /media/usbdrive/dcim ? -jef Hi, this is fixed in Rawhide; you'll need gnome-volume-manager 0.9.10-2 and hal-0.2.97.cvs20040901-1. If you have changed the defatuls in the "Removable Storage" preferences capplet, you need to set 'gthumb-import %h' as the command to invoke when importing digital photo albums. confirm fixed gthumb-import %h opens in the directory. One thing.. do you want it to open into the dcim subdirectory by default? instead of the top directory of the media? -jef David, does all photo media have the dcim subdirectory? If so then yes. Actually I can just put a test in the script to see if it exists and use that directory if it does. Any objections? Yeah, although dcim may be in uppercase as well IIRC. Putting it in the script will help but the user will still have to select the subdir with the pictures and this is camera specific. My camera uses canon122 and so forth. All detailed in DCF, see http://www.exif.org/dcf.PDF (btw this doc raises some interestering requirements for the Perfect(tm) photo mgmt app; e.g. Reader 2 playback; ask to print tagged pictures etc.) Also note that there may be several subdirectories below DCIM if the media has been used with different devices. my point is... if the request for importing the pictures from media is done just by checking for a dcim or DCIM directory to even get the dialog, it makes some sense to open up to the dcim directory becuase im not all that sure that Al "the average user" Consumer is going to know that DCIM is the directory to browse down into. If the existance of the dcim directory is indeed what triggers the prompt open up to that directory. My camera, and i would imagine other cameras. let me name the subdirectories under DCIM to some extent and I can even choose which directory to use from the camera menu... the menu item right above "do my taxes" and just below "save the whales." Regardless though, seeing a set of subdirectories named NikonXXX or CanonXXX is going to be much more intutitively understood as photo directories than DCIM. -jef"my 3 cents, you own me 1 penny in change"spaleta Hehe, I guess I should have posted earlier but this is fixed and holding for after FC3 test2 is out. The bug is not critical enough to hold up test2 in QA. The wrapper script just checks to see if the dcim or DCIM directory exists and uses that as the base directory. Just as refrence this should have been opened up as a new bug, not appended to an already closed bug. Closed for real this time ;-) |