HAL 0.1 release

Joe Shaw joe at ximian.com
Fri Oct 10 23:26:58 EEST 2003

On Fri, 2003-10-10 at 15:25, David Zeuthen wrote:
> On Fri, 2003-10-10 at 20:56, Joe Shaw wrote:
> > The point is, having both category and capabilities seems to me like an
> > arbitrary distinction.
> Uhhmm.. yes.. but how do you determine the icon of your camera since it
> has got both camera and storage capabilities? 
> I think it should be a camera both when it appears in the storage list
> and in the camera list. 

Maybe, but it seems like it's getting bogged down in the details.  Maybe
we could have a "PrimaryCapability" or something like that, but I'm not

> Note, this *could* be bad UI, but the point is really that one cannot
> know this is a camera if you don't have category - alternatively we
> could look at the first capability?

Yeah, maybe.  It seems harder as you get into devices with multiple
purposes... my keyboard is a USB hub as well as a keyboard.  Does it
always show up as a keyboard even under the USB hub sections?  My
monitor has speakers built into it.  Does it show up as a monitor under
the multimedia section or as a sound device under the display section?

I am sure there are better dual-use examples than these where the line
gets very blurry, very fast. :)

> My initial point about having category/subcategory as well-defined is
> that it provides the name space where to store (optional) well defined
> properties that software using libhal might use. 
> So for Category=Network, SubCategory=Modem we would have
> Network.Modem.Initstring=ATZblah. Seth's networking profile work could
> read this initstring when using that modem.
> I suppose we can do this by just prefixing with capability name instead?

Yeah, I think that's a good idea.

> What capabilities could a device have? My guess
>  Camera 
>  AudioPlayer
>  Storage
>  Networking
>  PDA
> and maybe more: Bridge, Processor.. Is this stretching it?

These all seem sane.  I would mostly just play it by ear at this point. 
Ones like AudioPlayer and PDA may need some refining as we get a better
handle on scope and use cases.


More information about the xdg mailing list