info.icon in HAL

[Rodney Dawes]

On Fri, 2007-03-02 at 13:25 -0500, David Zeuthen wrote:
> Hmrh, so I think it was a little premature to just post this without
> thinking about the ramifications and explaining what we're trying to
> achieve. So here goes

>  - Second, icon-naming-spec defines more than just names - it defines
>    the structure of how icons are named. So, for example, if HAL says
>    "the i-n-s name for this device is phone-danger-hiptop-version3"
>    then the desktop bits rendering the icon can be smart about it.
>    Because they _know_ about the structure and call fallback to more
>    generic icons if the specific icon is not available; for this
>    example the following icons are searched for in order of preference

There is a patch to GTK+ in bugzilla, which adds support for doing this
sort of fallback from the specification, inherently in GtkIconTheme. I
don't know what the situation is in KDE with regards to it.

>  - As such, we should try to provide this information to applications.
>    We're going to do that in _three_ ways
> 
>    - One is via hal-info where we can match on e.g. USB vendor and
>      product id's and merge a property, say, info.icon_naming_spec_name.
>      This is no different from what we do to identify e.g. the different
>      LUN's on a Nin1 card reader.

As we agreed on IRC, I think info.icon_name is sufficient for the
property name. I'll be implementing my patches to various items, this
way, and submitting them shortly.

>    - We can also compute the name if info.icon_naming_spec_name is not
>      available. Now, we don't want to waste cycles computing names if
>      they are not available so perhaps some method either in libhal
>      or the main hald process will do this [1]. So here I think that we
>      simply offer a method on the standard o.fd.Hal.Device interface
> 
>       GetIconNamingSpecName()
>       (wrapped in libhal as libhal_device_get_icon_naming_spec_name())
> 
>      that does this thing. So if info.icon_naming_spec_name is set
>      we use that one; if it isn't we compute it. And here's how:
> 
>      It's not hard really, for e.g. devices of capability
>      "portable_audio_player" we do the right thing and give the name
> 
>        multimedia-player-<vendor>-<product>
> 
>      by default. We will have to coordinate with i-n-s developers on
>      what the names are as we get vendor names for USB devices from
>      /usr/share/hwdata/usb.ids and these are very long and in all-caps
>      e.g. 
> 
> 		0b4b  Pine Corp. Ltd.
> 		        0100  D'music MP3 Player
> 
>      and that would give us 
> 
>        "multimedia-player-Pine Corp. Ltd.-D'music MP3 Player"
> 
>      which isn't that nice.

Or valid, according to the spec. For this particular device, the right
name is probably "multimedia-player-pine-dmusic". But yes, there will
definitely have to be coordination, as naming is often hard, given that
many devices provide many different forms of functionality.

>  Perhaps the i-c-n should reference the Id's
>      so the name becomes
> 
>        "multimedia-player-usbv0b4b-usbp0100"
> 
>      but that is hardly friendly for the graphics designers.

As you pointed out on IRC, this isn't really a good idea.

>  Either way,
>      the point here is that some mapping from hardware to names is
>      needed. Perhaps we just punt this one and we always assign just the
>      name "multimedia-player" if info.icon_naming_spec_name isn't set
>      and as such just rely on hal-info to provide the right name. That
>      really depends on what the i-n-s developers think.

I think we should use the generic icon if the name isn't set. This means
that we'll always get an approximately good icon for the device, and it
is most likely going to be the icon you'll end up with anyway, if you
did compute a full name. I am definitely glad to see this finally
getting somewhere though. Having the Nokia N800 get a proper icon when I
plug in the USB, is awesome [1].

-- dobey

[1] http://wayofthemonkey.com/nokia-n800-icons.png