info.icon in HAL

[David Zeuthen]

On Thu, 2007-03-01 at 22:41 +0000, Richard Hughes wrote:
> Attached patch adds info.icon to the spec. It's expected that all the
> icon logic be in hal-info, for which another patch is attached.
> 
> See http://wayofthemonkey.com/?date=2007-03-01 for details.
> 
> Comments please,

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

 - First, icon-naming-spec (from here i-n-s) is an awesome thing; In
   general it will help solve some difficult problems with how icons are
   named and  will help cross desktop efforts such that KDE apps don't
   look foreign on GNOME and vice versa.

 - 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

     phone-danger-hiptop-version3
     phone-danger-hiptop
     phone-danger
     phone

 - 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.

   - Second is via probers; here I expect e.g. libipoddevice to set te
     info.icon_naming_spec_name property after it have investigated the
     device. For this particular example, it will choose e.g. 
     "multimedia-player-apple-ipod-mini-pink" if you have a pink iPod
     mini. So libipoddevice already runs a callout and I hope (and
     think) the libipoddevice team will make this change (it already
     runs HAL callouts).

   - 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. 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. 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.

Thoughts?

     David

[1] : not everyone uses libhal (e.g. Banshee) and I want to see move
away from libhal to using D-Bus bindings.