Re: gvfs hal volume monitoring backend

[Alexander Larsson <alexl redhat com>]

On Mon, 2007-12-17 at 17:43 -0500, David Zeuthen wrote:
> > All the volume manager code just uses a single name for the GIcon. Why
> > not use a set of icons
> 
> I actually thought the gtk+ code using this would use the newly
> introduced GTK_ICON_LOOKUP_GENERIC_FALLBACK that is available as of
> 2.12... 

That is not good enough in general. Take mimetypes for instance, say you
have an openoffice writer file. The most detailed icon would be the one
for the writer mimetype, but if that is not availible you want to
fallback to a generic word processor file icon. For some mimetypes this
might be doable by just dropping parts of the name (like
GENERIC_FALLBACK), but for many (like all application/x-* types) it
doesn't.

I've discussed adding information about this to the mime spec a bunch of
times on the xdg list. Nothing has been finalized, but the obvious
conclusion is that you want to support a list of icon names (supported
by GThemedIcon), and you want to look it up in a proper fashion where
you check availibility of each name in the list before going to the
inherited theme (possible with gtk_icon_theme_choose_icon).

> Since I just introduced a fast path for getting info from hal [1] it's
> not really more expensive, IO wise anyway, to construct a full volume
> monitor.

No more i/o operation, but the operation you do is more complex and
recieves more data.

> In the majority of cases (nautilus, file chooser) the caller will
> already have a volume monitor so there's no penalty for them. I can't
> think of any apps without a volume monitor that would need to call it.

Sure, if we have one, that is probably a good thing to use.
 
> > The way this is handled by g_vfs_get_default() is that the instantiated
> > GVfs object is checked with g_vfs_is_active() to make sure that
> > construction was successful. This is the general pattern used for this
> > in GObject. As there is no exception handling in GObject it is not
> > generally allowed for construction to fail.
> > 
> > I'll start working on these details in svn.
> 
> (cont'd from above paragraph) 
> 
> ...this is done (sounds like you are doing it? otherwise I can look into
> it).

I handled this (although i had to do it a bit differently).