Re: [gfvs] cdda backend

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-12-20 at 10:45 -0500, David Zeuthen wrote:
> On Thu, 2007-12-20 at 11:57 +0100, Alexander Larsson wrote:
> > So, I guess the question is, in what way is it better to have
> > "public_html @ p.fd.o" be a volume than using a bookmark for this?
> 
> I suppose either works; it was just an idea. The main advantage is that
> the icon for the volume wouldn't jump around (bookmarks IIRC are stored
> below a separator line in the file chooser and sidebar) if you double
> click it in the file chooser. I think bookmarks are more intended for
> files or folders? I don't know.

Bookmarks are for folders (you get default bookmarks for things like the
photos folder, etc). 

I'm not saying I know what is best, just that its not obvious what the
best route is.

> > >  gboolean (*request_adoption_of_orphan_mount) (GVolume *adopter,
> > >                                                GMount *orphan);
> > > 
> > > that each implementation can implement? Alternatively we can put this
> > > method on the GMount interface but that seems wrong since it's only
> > > something volume monitors would ever want to do.
> > 
> > The volume monitor would recurse over all volumes and call this?
> > 
> > Isn't it better to have something like: 
> > 
> >  GMount * (*find_orphan_mount_for_adoption) (GVolumeMonitor *monitor,
> >                                              GVolume *adopter)
> 
> Actually with the proposal I had, the adoptor itself would iterate over
> all mounts and use it's own criteria of how to pick an orphan - it's
> probably in a better position to choose than the orphan's volume
> monitor? I mean, suppose we did "fav servers" as a GVolume stemming from
> a "fav servers" volume monitor; how would GDaemonVolumeMonitor know how
> to pick adopter? 

Hmm, i guess. But how can the fav server volume monitor iterate over all
mounts? It doesn't see other volume monitors.

> Sure, we can do that as well (putting the calls to lsof(8) into the code
> creating the dialog). It just seems like a waste to not abstract this
> stuff out. There's GPid in glib already so am not sure why this isn't
> portable (list_open_files() would be allowed to error out with
> G_IO_ERROR_NOT_SUPPORTED of course).

Well, any time you expose an abstraction like this you limit both how
the backend can work, and what details you can show in the dialog. Plus
you add more stuff to the API that most people really don't need.

What would list_open_files() returns? A list of a new kind of GObject?

> Btw, I wouldn't be so sure about busy mounts; what if you keep you
> media collection on a networked share? People are working on moving
> people's documents and media off the client and on to hosted storage
> services; it seems we'll be getting more of this. (And you can cwd into
> ~/.gvfs too but I agree that is not so common).

You mean while the player plays a media file it would be busy. I guess
thats not to uncommon. pwds in ~/.gvfs don't keep the GVfs busy, as
~/.gvfs is just a single mount.

> The rationale for the patch is to
> 
>  - define "what could be on the media" means (x-content/*)
>  - unify all sniffing code into a single place
>    - likely pluggable so 3rd party libs (like libipoddevice), that
>      actually handle dealing with the device in question, can
>      participate
>      - involves name and icon selection too
>  - encourage people to use (and write) gvfs backends instead of using
>    Linux/UNIX-only libraries in their apps thus rendering non-portable
> 
> Because, right now, it's a mess and every app (including the auto
> mounter) does their own thing. The result, as you can see from the
> screenshots, is that things not only look different, the names are
> different too. (and ideally, there would be a stock "select_media"
> dialog where you pass one or more x-content/* identifiers.)

Sounds like a good reason.

> Of course, it's fine if this is not a goal for gio but then volume
> monitor API of gio isn't really useful outside the file manager and the
> file chooser and should perhaps be private API instead.

I just want to make sure we don't add something that apps can't use that
we have to support forever. We need to make sure all APIs are right,
sane and useful. I'm tired of maintaining big-bag-of-crap libraries...