---- 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: Eject Media (Open)
related to shotwell - 5585: Find a workaround for libgphoto2 blocking (Open)
related to shotwell - Feature #2841: 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

####

#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.

####

#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…

####

#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

####

#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

####

#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)
consistent with those that appear on the GNOME desktop.

Worth considering for 0.9.

####

#6

Updated by antistress - about 3 years ago

excellent, version 0.9 will kick ass ;-)

####

#7

Updated by Ernst - almost 3 years ago

This would be a great fix IMHO!

####

#8

Updated by antistress - almost 3 years ago

is it still on the radar for 0.9 milestone ?

####

#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.

####

#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

####

#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.

####

#12

Updated by antistress - almost 3 years ago

That's good news :-)

####

#13

Updated by Jim Nelson almost 3 years ago

See also #1903.

####

#14

Updated by Jim Nelson over 2 years ago

See also #2738

####

#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.

####

#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%..

####

#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.

####

#18

Updated by Adam Dingle over 2 years ago

  * **Target version** deleted (<strike>_0.10_</strike>)

####

#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

####

#20

Updated by Jim Nelson 11 months ago

  * **Target version** set to _0.14.0_

####

#21

Updated by Jim Nelson 11 months ago

  * **Category** set to _camera_

####

#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.

####

#23

Updated by Jim Nelson 8 months ago

  * **Target version** changed from _0.15.0_ to _0.16.0_

####

#24

Updated by Jim Nelson 6 months ago

  * **Target version** deleted (<strike>_0.16.0_</strike>)

####

#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