HAL 0.1 release
david at fubar.dk
Sat Oct 11 02:46:38 EEST 2003
On Sat, 2003-10-11 at 00:14, Havoc Pennington wrote:
> Another option is for each device to have:
> Interfaces = Modem, HayesModem, Network, Disableable, PCIDevice
Ok, this is what is discussed in another part of the thread only with
the word "Interfaces" being replaced by "Capabilities" (in plural to
indicate it's a list).
To move on, trying to conclude, can we all agree that
1. Capabilities (I'd rather use this word, "Interface" is quite over-
loaded) is a list of keywords that is not (necessarily) derived from
the hardware but must be provided in device info files.
It is always required and cannot be empty.
2. We need to define each keyword appearing in Capabilities in the
HAL spec. At the end of the day, it's really two things:
a) up to what libs/apps we use, to handle this, e.g. libraries
advertise they can handle devices with a set of Capabilities.
For instance the netprofile work as outlined by Seth might
search for capability "Networking", while a modem dialer
library might search for "HayesModem". libghoto might handle
"Camera" and Rhythmbox might handle "AudioPlayer"...
b) Hints to the desktop environment 'what the devices does', not
'what it is'
I don't think we neccesarily need to think in terms of
inheritance. And I think we can grow the list of capabilities
over time as we get more support. So apps/libs would pull in
new capabilities and other required properties as time goes.
3. 'Physical device'  attached with multiple interfaces will appear
as a single HalDevice object. For example USB speakers will have
"Capabilitiy = HID, Speaker"
4. 'Physical device'  (like the printer Bryan mentioned) with
multiple device-level objects each with a single interface
will appear as many HalDevice objects.
5. We require the PrimaryCapability property to be set to convey
the primary usage of the 'Physical device' . This can be
used to look up an icon using the icon-theme-spec
We could also use the first capability mentioned as the 'primary
capability'; either way works for me.
If we can agree on this, I'll merge this into a version 0.2-work-in
-progress of the spec.
ps. : I like the Disableable capability!
 : Using just 'device' is not sufficient in this thread. What I mean
is really 'the expensive new box with many buttons and other
geeky stuff that you attach to your system'
> And each interface in the list implies that specific properties will be
> present. There would then be no separate "device category", to get all
> cameras you just check for devices that support camera operations.
> On the down side, maybe sometimes you'd have empty interfaces existing
> just so you can see if the device is_a particular sort of thing.
> 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!
More information about the xdg