Re: Fixing gvfs-backend-afc for iPhone/iPod Touch access
- From: "Martin S." <info sukimashita com>
- To: gvfs-list gnome org
- Subject: Re: Fixing gvfs-backend-afc for iPhone/iPod Touch access
- Date: Wed, 05 Aug 2009 13:59:31 +0200
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]