camera locked dialog is confusing
Submitted by Adam Dingle
Link to original bug (#716271)
Description
---- Reported by adam@yorba.org 2010-04-22 09:31:00 -0700 ----
Original Redmine bug id: 1813
Original URL: http://redmine.yorba.org/issues/1813
Searchable id: yorba-bug-1813
Original author: Adam Dingle
Original description:
If Shotwell is running and I connect an iPhone, then after a long delay in which Shotwell is hung (#1812 (closed)) I see the iPhone in the sidebar. If I then click on it right away, I'll always see a dialog stating that it's locked by another application. If I don't close that dialog then other bad things may happen (#1811 (closed)) but, more fundamentally, the dialog is confusing to the user, who will probably not know who has the phone locked or what to do about it. The reality is that Nautilus has the phone locked and will release it shortly, once it's mounted, so all the user has to do is wait a few seconds and try again. We could add a dialog button that makes it easier for them to do so (#391 (closed)), but they are still likely to be confused.
I think it would be better if in this situation we simply waited until after Nautilus has released the lock before showing the phone in the sidebar; then the user would never see the camera locked message. I know this might not be so easy to implement, however.
As an alternative, perhaps we could display a message “Waiting for camera to be unlocked…†with a Cancel button. Then the user could simply wait and the right thing would happen. If another application such as F-Spot is using the camera, the dialog might not vanish for a while and the user would have to cancel.
Related issues:
- related to shotwell - Feature #2498 (closed): use GVFS rather than libgphoto2, allowing importing witho... (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:44:00 -0700 ----
History
Comment 1
Updated by Adam Dingle over 3 years ago
- Subject changed from camera locked dialog is confusing to [strings] camera locked dialog is confusing
Comment 2
Updated by Jim Nelson over 3 years ago
I've looked into this problem. It's even more complicated than it seems.
Normally Shotwell will detect that the camera is locked and mounted and ask the user if they want Shotwell to unmount it for them. The reason you saw the message “The camera is locked by another application†instead is because Nautilus was in the middle of mounting it as a filesystem -- the camera was locked but the mount point was not yet available. Shotwell does not know that the mount point is coming, so it assumes that another application (i.e. F-Spot) is holding the lock.
The first solution is tempting, but that doesn't guarantee that the lock message will never be encountered. F-Spot, for example, might be executed. The only true way to avoid it is to do something like the following:
When the camera is detected, in a background thread begin attempting to lock the camera until it's been acquired. (The only way to know if the camera is locked is if our lock fails; there might be a way around this, but it would take more research.)
If the lock fails, see if Nautilus has mounted it. If so, we'll need to ask the user if they want to unmount; doing that automatically would be lethal. When it's been unmounted, we can then attempt to acquire the lock again.
Once the lock is acquired, hold the lock for the duration of the application. That would be the only way to be sure we'd not be locked out again.
I don't like this.
The second alternative is worth looking into. It would go something like this when the user clicks on the camera.
Put up “Waiting…†dialog box.
In background thread, attempt to acquire the lock.
If locked, see if there is a mount point. If yes, ask user if we should unmount it. Once unmounted, goto 2.
If locked but no mount point, wait a bit. Goto 2.
If not locked, we now hold it. Exit thread and close dialog box.
I'm going to look into this alternative.
Comment 3
Updated by Adam Dingle over 3 years ago
-
Priority deleted (
<strike>
_High_</strike>
)
Jim has looked into this and has done some work toward implementing a fix, but we think this would be too large a change for 0.6 at this point. Dropping to medium.
Comment 4
Updated by Adam Dingle over 3 years ago
- Subject changed from [strings] camera locked dialog is confusing to camera locked dialog is confusing
Comment 5
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 6
Updated by Jim Nelson 11 months ago
- Category set to camera
Comment 7
Updated by Jim Nelson 10 months ago
- Target version changed from 0.14.0 to 0.15.0
Comment 8
Updated by Jim Nelson 8 months ago
- Target version changed from 0.15.0 to 0.16.0
Comment 9
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.16.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:45 UTC ---
This bug was previously known as bug 1813 at http://redmine.yorba.org/show_bug.cgi?id=1813
Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution