shotwell

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.

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…

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

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

excellent, version 0.9 will kick ass ;-)

This would be a great fix IMHO!

is it still on the radar for 0.9 milestone ?

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.

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

That's good news :-)

See also #1903.

See also #2738

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.

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

I hope that this will be a goal for 0.11 august release.

This remains the main usability bug in Shotwell

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.