use GVFS rather than libgphoto2, allowing importing without unmounting
Submitted by Adam Dingle
Link to original bug (#716499)
Description
---- Reported by adam@yorba.org 2010-08-30 10:41:00 -0700 ----
Original Redmine bug id: 2498
Original URL: http://redmine.yorba.org/issues/2498
Searchable id: yorba-bug-2498
Original author: Adam Dingle
Original description:
It would be nice if we could somehow import photos without unmounting the camera. This would simplify the user interaction and make it easier to use Shotwell and other applications (e.g. Nautilus) at the same time. I don't know if this would be easy. On the mailing list, Thibaut Bethune pointed out that at least one other application seems to do this:
Maybe you could look at phraymd (Python application) which succeed in importing photos without unmounting the camera, which seems to be the only way to proceed. For what i know i think that spillz (phraymd developper) makes use of GVfs for that. Once he pointed out the GVfs FUSE hack explained here : http://davidz25.blogspot.com/2008/10/getting-gvfs-and-fuse-right.html, adding : “Of course, the GVfs API provides higher level access than what FUSE gives, so I will ultimately use that in phraymd.â€
Related issues:
- related to shotwell - 4992: Shotwell displays RAW previews on camera but not on flash... (Fixed)
- related to shotwell - 4943: ignore auxilliary AVCHD video container files when import... (Fixed)
- related to shotwell - Feature #2880 (closed): Eject Media (Open)
- related to shotwell - 5585: Find a workaround for libgphoto2 blocking (Open)
- related to shotwell - Feature #2841 (closed): Generate thumbnails on import page if file is small enough (Open)
- related to shotwell - 1813: camera locked dialog is confusing (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-06-01 12:56:00 -0700 ----
History
Comment 1
Updated by Adam Dingle about 3 years ago
By the way, F-Spot 0.6.1.5 on Ubuntu Lucid is also able to import photos without unmounting. I just tried an experiment and was able to open a photo on my iPhone through Nautilus while an F-Spot import was in progress.
Comment 2
Updated by antistress - about 3 years ago
also while i was asking how Nautilus can handle camera-%(=caps)PTP%-mode-only, Martin Pitt once wrote to me :
“gvfs has a module for libgphoto, and exports a “fake†gvfs file system for the
camera. gvfs also sets up a fuse file system for any gvfs-supported
file system (smb, ssh, gphoto, and whatnot) und provide it as a fuse
file system in ~/.gvfs/.
Nautilus has proper support for gvfs/gio, so it doesn't need those
fuse file systems. But other applications can use the fuse system to
interact with GNOME-mounted gphoto, ssh, samba, or other virtual file
systems."
I hope it can help. Sorry, i'm not a developper and then can't say more…
Comment 3
Updated by antistress - about 3 years ago
Concerning phraymd, you may want to check lp:phraymd from rev. 319 and specially rev. 319, 320, 330, 332…
see https://code.launchpad.net/~damien-moore/phraymd/trunk
Comment 4
Updated by antistress - about 3 years ago
Honestly the dialog box asking the user to unmount the camera is a big mistake regarding the user experience
You'll find some references at the end of that post https://bugzilla.gnome.org/show_bug.cgi?id=586003#c22
It seems to me that this bug should be classified High (at least)
One solution would be to automatically unmount the camera and inform the user in that way http://codinghorror.typepad.com/.a /6a0120a85dcdae970b0120a85dd75f970b-pi (from that blogpost http://www.codinghorror.com/blog/2004/06/death-to-the-dialog-box.html ) (using GtkInfoBar ?)
A better solution would be that Shotwell could import photos without unmounting the camera just like phraymd does
Comment 5
Updated by Adam Dingle about 3 years ago
- Subject changed from possibly import photos without unmounting to use GVFS rather than libgphoto2, allowing importing without unmounting
Both F-Spot and gThumb now use this approach, and don't talk to libgphoto2 directly. Another benefit is that we'd get nicer camera names (#854 (closed)) consistent with those that appear on the GNOME desktop.
Worth considering for 0.9.
Comment 6
Updated by antistress - about 3 years ago
excellent, version 0.9 will kick ass ;-)
Comment 7
Updated by Ernst - almost 3 years ago
This would be a great fix IMHO!
Comment 8
Updated by antistress - almost 3 years ago
is it still on the radar for 0.9 milestone ?
Comment 9
Updated by Adam Dingle almost 3 years ago
We discussed this at Yorba yesterday. This change would be non-trivial, and its visible user benefits would be small compared to some of the other changes we're considering (e.g. a search box and hierarchical tags). So I now expect this will not happen for 0.9. Maybe in 0.10 or 0.11.
Comment 10
Updated by antistress - almost 3 years ago
I would have understood that it would have to be delayed because of technical reasons but i can't understand that you consider that “user benefits would be small compared to some of the other changes [you]'re considering (e.g. a search box and hierarchical tags)â€.
Honestly this is a major default in current UI. Remebre the rule : “every time you send your users to an alert dialog, you have failed themâ€
Not all users are familiar with internals of an OS : a lot of users don't even know what is a file system or what (un)mounting means !!!
Shotwell aims to be /already is default applications in a lot of distributions.
A lot of people that may use it have no particular computer skills.
1st experience with Shotwell for these people will not only be intimidating ; they will be paralyzed : “I don't understand the choice, what shall i do ?†“I don't want to damage the computer†etc.
Please look at current shotwell experience from a beginer point of view. He just can't use it ! How could he care about search box or hierarchical tags ?
Trust me : my father tried shotwell and he couldn't overcome the obstacle.
That was very embarassing to me to set up its computer, installing Ubuntu, and to tell him in front of Shotwell : “you have to answer this but don't be disappointed you couldn't knowâ€.
Please, i'm not begging you to implement a particular functionality that i would like to see in Shotwell and that could suit my needs, i'm pointing a major usability bug in which application is asking the user a question that he probably don't know the answer and that should be answered by the application itself, letting the user confused. This is a terrible user experience.
This bug's priority should be high
Thanks
http://clarkbw.net/blog/2007/04/30/dont-do-what-i-want/
http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html
http://www.joelonsoftware.com/uibook/chapters/fog0000000062.html
Comment 11
Updated by Adam Dingle almost 3 years ago
- Priority set to High
I'll up the priority to high for consideration for 0.10 or 0.11. Again, this wouldn't be super easy, but may still be worth doing for the reasons you point out.
Comment 12
Updated by antistress - almost 3 years ago
That's good news :-)
Comment 13
Updated by Jim Nelson almost 3 years ago
See also #1903.
Comment 14
Updated by Jim Nelson over 2 years ago
See also #2738 (closed)
Comment 15
Updated by Damien Moore over 2 years ago
Maybe I'm missing something fundamental, but I think you could get away with a quick and dirty fix for this bug:
1/ Retrieve the FUSE path for the device. You can use the FUSE path (in ~/.gvfs) to enumerate the filesystem and later copy files to the users collection directory without too much of a performance hit.
2/ Get thumbnails for the images on the device using GIO calls (it's ridiculously slow to acquire the thumbnail by reading directly from the FUSE path on an MTP camera).
Here's the python code I used in phraymd for working with GIO volumes and retrieving the FUSE path of the mount
http://bazaar.launchpad.net/~damien- moore/phraymd/trunk/view/head:/modules/phraymd/io.py#L69
Note the m.get_root().get_path() in response to the “mount-added†signal
Here's a link to the python code I used to get the thumbnail:
http://bazaar.launchpad.net/~damien- moore/phraymd/trunk/view/head:/modules/phraymd/imagemanip.py#L571
Seems like this would be fast to implement by creating a GVFS/%(=caps)FUSE%-based module with the same (or similar) interface as the gphoto module defined at:
http://trac.yorba.org/browser/shotwell/trunk/src/camera/GPhoto.vala
then enable as a compile or runtime option.
Comment 16
Updated by Landry Breuil over 2 years ago
Just a sidenote… GVFS/%(=caps)FUSE% works fine on Linux, i'm not sure for FreeBSD, NetBSD has puffs which is equivalent in features but i'm not sure it works, and OpenBSD doesn't have FUSE at all. Our GVFS works for ftp/webdav/ssh/smb, but i've never tried the gvfs/libgphoto2 part, and i think it requires %(=caps)FUSE%…
I can understand that you want to rely on GVFS instead of libgphoto2, but if possible (ie doesnt make the code too unmaintainable) make that optional and keep libgphoto2 as a fallback for oses not having a full GVFS/%(=caps)FUSE%..
Comment 17
Updated by Adam Dingle over 2 years ago
- Target version set to 0.10
Not sure we want to implement this for 0.10, but putting on the table for discussion.
Comment 18
Updated by Adam Dingle over 2 years ago
-
Target version deleted (
<strike>
_0.10_</strike>
)
Comment 19
Updated by antistress - over 2 years ago
I hope that this will be a goal for 0.11 august release.
This remains the main usability bug in Shotwell
Comment 20
Updated by Jim Nelson 11 months ago
- Target version set to 0.14.0
Comment 21
Updated by Jim Nelson 11 months ago
- Category set to camera
Comment 22
Updated by Jim Nelson 11 months ago
- Description updated (diff)
- Target version changed from 0.14.0 to 0.15.0
This is too large an undertaking for 0.14. We'll reconsider in 0.15 timeframe.
Comment 23
Updated by Jim Nelson 8 months ago
- Target version changed from 0.15.0 to 0.16.0
Comment 24
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.16.0_</strike>
)
Comment 25
Updated by Joe Bylund 6 months ago
I vote against gvfs. Gvfs and Thunar (default xfce file browser) have never worked terribly well together, and gvfsd-trash has a nasty bug where it consumes 100% of cpu.
--- Bug imported by chaz@yorba.org 2013-11-25 21:46 UTC ---
This bug was previously known as bug 2498 at http://redmine.yorba.org/show_bug.cgi?id=2498
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