HAL 0.1 release

[David Zeuthen]

On Sat, 2003-10-11 at 05:57, Havoc Pennington wrote:
> On Fri, 2003-10-10 at 19:46, David Zeuthen wrote:
> > > BTW, for the icon problem - I'd expect devices to have an Icon property,
> > > returning an icon name to be looked up using the icon theme spec.
> > > 
> > 
> > Thinking that this should be optional, I'd rather use the fact that the
> > capabilities list is ordered. Also the console tools for hal, such as
> > lshal, won't show icons!
> 
> Properties are optional, no? They don't have to be provided (and if
> provided don't have to be used).
> 

Not all properties are optional. Some of them we really need, like Bus,
PrimaryCapability, State to give some minimum functionality. 

I think this is OK to require - some of it is probed (Bus), some if it
is for book keeping (State), while some (PrimaryCapability,
Capabilities) *may* be probed, but should be overridden for
cosmetic/usability reasons in device info files

(The camera that is probed with PrimaryCapability=Storage may set
PrimaryCapability=Camera, Capabilities=Camera, Storage).

PrimaryCapability really answers 'what is the point of the gadget?',
while Capabilities answers 'what can the gadget it do?'. These are not
questions we can answer directly from the hardware probing; but the
answers to those is important in UI - selecting an icon is important,
but there may be more important reasons.

Note that in the camera example, the actual camera might just resemble a
USB keychain gadget to the probing software and it can only be accessed
as storage. Nonetheless, we want to display a camera icon, and we want
libraries that can access it is a camera, e.g. provide getPictures(),
even though it is only available as a storage device.

If this particular camera doesn't have a device info file, then it would
just appear as any other storage device (matching on a "generic storage
device" device info file) and the user would still be able to access it
- but he might get confused that his desktop is calling it a storage
device and not calling it a camera.

Some examples may be useful to further show that it is required to put
this in device info files, e.g. it is not available from the hardware
bits:

 # USB speakers with buttons on the front
 PrimaryCapability=Speakers
 Capabilities=Speakers, Keyboard

 # Keyboard with built-in speakers
 PrimaryCapability=Keyboard
 Capabilities=Speakers, Keyboard

 # A fancy USB printer with many features
 PrimaryCapability=Printer
 Capabilities=Printer, Scanner, Fax, Storage

 # MP3 player that can also be used as storage
 PrimaryCapability=AudioPlayer
 Capabilities=AudioPlayer, Storage

 # Camera that only provides storage interface
 PrimaryCapability=Camera
 Capabilities=Camera, Storage

 # Camera that doesn't provide storage interface
 PrimaryCapability=Camera
 Capabilities=Camera

 # Camera with builtin printer
 PrimaryCapability=Camera
 Capabilities=Camera, Printer

 # Printer with builtin camera
 PrimaryCapability=Printer
 Capabilities=Camera, Printer 

Most of the time though, fancy multi-interface devices (like the printer
Bryan got), appears as multiple USB devices to the system, and thus it
will appear as multiple HalDevice objects with each having a single
capability. I guess this is all fine.

> Seems to me you want the devicetype->iconname mapping to be somewhere,
> and logically it's in libhal. Where else would you put it?
> 
> A simple alternative is to make the mapping a mechanical one. 
> For example, if the device type is Foo, the icon is also named Foo. This
> would reduce the icon problem to a one-liner in either the HAL spec or
> icon theme spec. Only issue here is namespacing (what if you have a
> device type Foo and also an application named Foo, or whatever); icon
> theme spec has the idea of contexts IIRC that may solve that.

We can put it in libhal, that's fine with me. I'm hoping this will be
clarified once someone works on the UI bits.

> Re: using ordering to indicate the primary device, I'd say that's pretty
> fragile/"magic". I'd rather see an explicit property Primary=Foo or
> something.
> 

You mean s/primary capability/primary device/ right? If so, yes, Marc
also got some good points about this, so my thinking is we will require
both

 PrimaryCapability, Capabilities

to both be present and non-empty for each and every device. We need to
define in the spec what capabilities there are, but this can grow over
time.

David