Re: the one true gphoto method?

[David Zeuthen <david fubar dk>]

Hi,

On Fri, 2009-06-05 at 19:43 -0400, Dr. Michael J. Chudobiak wrote:
> Alexander Larsson wrote:
> >>>
> >>> However, some distros are shipping with the gvfs backend for gphoto, 
> >>> which means that gio users can share a camera, but old apps using 
> >>> libgphoto2 are broken because the gvfs backend locks them out.
> > 
> > I also want to mention that it seems like your initial problem was that
> > you wanted to get the thumbnails from the camera via libgphoto. In
> > current versions of gvfs you can get these directly by asking for the
> > G_FILE_ATTRIBUTE_PREVIEW_ICON attribute (its a GIcon that you can use
> > with e.g. gtk_image_set_from_gicon).
> 
> What if the camera (or card reader) mounts as USB mass storage under 
> /media, and thus doesn't use the gphoto backend?
> 
> ligphoto could still provide a thumbnail/preview for that, same as a PTP 
> camera. However, if we drop libgphoto entirely and migrate to gfile 
> instead, I think we lose that ability, and we'd have to generate a 
> thumbnail ourselves. Am I right?

Yeah, First, to generate thumbnails you should just use this function

http://library.gnome.org/devel/gnome-desktop/stable/GnomeDesktopThumbnailFactory.html#gnome-desktop-thumbnail-factory-generate-thumbnail

to generate a thumbnail. If the GVfs backend, such as the gphoto2 one,
supports G_FILE_ATTRIBUTE_PREVIEW_ICON then things are very fast since
it gets the thumb directly from the camera. I believe the thumbnails
will also be shared with other apps using these functions, such as
Nautilus.

(Btw, we probably need async versions of these functions in
libgnome-desktop but for now you can run it in a thread yourself if
that's needed.)

Second, if the gphoto2 is using a backend for where it reads data from a
kernel mount (such as /media/EOS_DIGITAL), then gphoto2 will have to
synthesize the thumbnail from the full file so it wouldn't be faster or
slower than what GnomeDesktopThumbnailFactory would be doing.

     David