Re: Fixing gvfs-backend-afc for iPhone/iPod Touch access

["Martin S." <info sukimashita com>]

On Wed, 2009-08-05 at 10:46 +0100, Bastien Nocera wrote:
> On Wed, 2009-08-05 at 10:05 퍭㐱ꫭ詴낮譞:
> > Once we get some icons for multimedia-player-apple-ipod-touch and
> > phone-apple-iphone in the distros (gnome-icon-theme I guess) things will
> > look neat aswell:
> > http://media.sukimashita.com/temp/gvfs-backend-afc-screenshot-1.png
> 
> Did you file a bug against gnome-icon-theme?

Yes, http://bugzilla.gnome.org/show_bug.cgi?id=590835

> > Stuff that is open and related questions:
> > 
> > - Nautilus does not "browse" the device on automount anymore (This
> > worked before we took the shadowing out. What enables it again?)
> 
> In the File Management preferences, select the Media tab, and tick
> "Browse media when inserted".

I never unchecked that option. This is related to some detail that got
missing after the shadow mount stuff was removed. I can't find the
difference there though. Perhaps nautilus-2.27.4 is the "bad guy" here.

> > - Run "indent xy" to apply GVFS coding style (What indent rules does
> > GVFS use?)
> 
> Don't know, but my vim rules will help. I'll try and do that today.

Superb, pushed it.

> 
> > - Merge the AFC backend tree with GVFS HEAD (Really? Why not keep the
> > benefit of an external/plugin backend with "special" dependencies like
> > libiphone? Ain't the ultimate goal to rip of backends into own modules
> > for easier maintenance?)
> 
> The gvfs API isn't public, so the current build system is probably
> alright for a test package, but you won't be able to use it in a build
> system with major hacking (eg. including a copy of gvfs in the sources).


Well, you need to have the gvfs sources somewhere and use the
"--with-gvfs-source=PATH" configure option. Afterwards everything should
work as usually.

For the distro packages I create, the GVFS source tarball is used as a
second source.

Apparently the build situation is the same for the GVFS synce backend,
too.

I agree that making the backends compile standalone would be the best
solution (but requires adjusting the API to be public).

Unless of course the GVFS crew loves to maintain a series of custom
protocol backends (and their individual quirks). :)

> 
> > - Port to libgudev (why not libudev btw? gudev = nicer API?)
> 
> GObject-ish API, means no need for you to implement your own main loop,
> or setup the watches on file descriptors. It lives in the main udev
> repo.

Ok.

--- Martin S.