a libary that can ask hald for a list of surten devices

[David Zeuthen]

On Tue, 2004-08-03 at 08:33 -0400, Joe Shaw wrote:
> On Tue, 2004-08-03 at 13:50 +0000, Kristof Vansant wrote:
> > I was thinking a common libary that can ask hald for surten hardware.
> > This could be interresting for surten programme's.
> > 
> > example: totem has an menuitem dvd and cdrom
> > 
> > if totem could ask the common libary to ask hald what media devices are
> > installed. totem can only show these devices. totem does not need to
> > have hald support itself.
> 
> This is generally the idea.  We hope that people will build their
> libraries on top of libhal for specific access to their hardware.
> 

Exactly. In fact, we also want to extend existing libraries to
optionally use libhal for device discovery.

At some point, I was pondering about writing a libhal-storage library,
basically, wrapping the HAL string API in some C structs (much like the
code in gnome-vfs-hal-mounts.c from gnome-vfs), but I decided against
that on the grounds that one-size-doesn't-fit-all.

> The whole goal of HAL though is device discovery and enumeration, so
> libhal can very easily do a lot of the work in get_scanners(),
> get_keyboards() itself.  I think rather than a single library for this
> enumeration you'd instead want a library which does a specific task
> well, like burning CDs/DVDs.  Then not only could you have nice
> convenience functions like get_cdr(), but you could also have things
> like set_burn_speed() and burn_disc().
> 
> And then you could also hide the HAL implementation details (although
> you'd still need to link against the library) if you wanted to have a
> non-HAL fallback.
> 

Right. Sometimes it makes sense to ''leak'' the HAL UDI though; this
what gnome-vfs CVS does. If gnome-vfs isn't built with HAL support of if
the drive or volume isn't from HAL (like a ssh:// volume) then it's
simply NULL.

But when it's not NULL then consumers of gnome-vfs, like Nautilus, can
take advantage of the HAL UDI and e.g. decorate the icon with emblems
and stuff or construct better default actions like "Start Music
Management Application" for a storage device which is in fact a MP3
player. Or "Start Photo Management Application" for a storage device
which is in fact a digital camera.

My hunch feeling is that it's most of time good to ''leak'' the HAL UDI
cause the UDI is a very stable opaque reference to the device you're
interested it and it enables applications or libraries on top of the
library to be further enhanced by using HAL.

> (BTW, I think the library you mention already exists for totem, called
> libbacon.  I might be wrong about that, though.)
> 

Nono, you're right, it's called libbacon, and it indeed got optional HAL
support. I'm not sure it's leaking the HAL UDI though.

Cheers,
David
_______________________________________________
hal mailing list
hal at freedesktop.org
http://freedesktop.org/mailman/listinfo/hal