Re: the one true gphoto method?

[David Zeuthen <david fubar dk>]

Hey Mike,

[moving this thread to gvfs-list]

On Thu, 2009-05-21 at 20:44 -0400, Dr. Michael J. Chudobiak wrote:
> Hi all,
> 
> How are gnome photo apps "supposed" to import photos these days?
> 
> Most apps still use libgphoto2 to import photos, and it works just fine, 
> with the minor proviso that it locks the camera while in use.
> 
> 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.
> 
> The current hackish solution is to unmount the gvfs mounts from the 
> desktop file [1]. This just feels evil.
> 
> The alternative is to use gio to transfer files, and ditch the direct 
> use of libgphoto2. Add a wrapper layer, in other words. Except the 
> libgphoto2 authors seem to have a very low opinion of the gvfs backend 
> [2], and don't recommend it.

Yes. I've asked Hub to file bugs but he never did. Either way, the
gphoto2 gvfs backend works fine for just about everyone else and when
people file bugs we promptly fix them. So go figure.

> We could also use gio when a gvfs mount is detected, and fallback to 
> libgphoto2 when the backend is not present. Which is just cranking up 
> the complexity.
> 
> Those who don't adopt one of those methods are "too lazy or something", 
> apparently [3].
> 
> The problem was noted a year ago at release time [4], but it's not 
> obvious to me that anything is better now.
> 
> I don't really see what the benefits of the gphoto gvfs backend are. So 
> we can share cameras - but how many different photo importers do you 
> need to run simultaneously?
> 
> So... is there an official line of thought here?

First, the free desktop is unquestionably a moving target so anyone
writing apps for it need to sometimes catch up either with ABI/API
changes or also changes on this level where things they took for granted
no longer is true. That's just the nature of how things work. See e.g.
all the audio debacle for similar issues.

Second, abstracting libgphoto2 out makes a lot of things a lot easier if
you are writing an application. Basically it means that you

 - can use a modern async API like GIO instead of the libgphoto2 API

 - we get support for browsing devices in the file manager for free
   - which happens to be a very nice feature that lots of people use

 - multiple apps (such as the file manager and your photo importer) can
   access the device at the same time

 - we can add/change other abstractions / device drivers without having
   having to change any apps

 - our autorun mechanism (the thing popping up dialogs when media with
   known x-content/* types are detected) expects a GMount to operate on.

   So if we yank the gphoto2 backend you no longer get this and you
   would need to add a lot of special case code which is hard to
   integrate and things would get more complex than they need to be.  

Third, I think a photo importer is broken if I can't pass it a path from
where to import photos from. E.g. if

 $ photo-importer /home/davidz/Photos

should always work.

Fourth, photo importers need to be able to import from mass storage
devices _anyway_ so they already need code that uses either GIO or POSIX
calls. And since you can use GIO through POSIX (via FUSE), then this
should already work fine. E.g.

 $ photo-importer /home/davidz/.gvfs/gphoto2 on usb:001,002/DCIM

should work. Otherwise it's an app bug.

Fifth, if you really insist on using libgphoto2 from your app, then

 - the user can manually unmount the gphoto2 mount

 - you can do system("gvfs-mount -s gphoto2") when libgphoto2 returns
   EBUSY (or similar things using the GIO API)

Sixth, please realize this is about moving the platform forward.. not so
much about making sure that apps written five years work unmodified. In
other words: this is progress.

     David