Truly dynamic icons?

Add-ons UIs
, ,
1

Hi All,

I did a bit of searching around and couldn’t find any similar topic or discussion (apologies if there is one!), but I wanted to see what people thought about using icon templates, and if this would be a simple thing to implement on openHAB2…

Currently from what I can see, for an icon to become “dynamic” it needs to have several versions of itself for different states. Now that both Classic and Basic UI can use SVG files, is there anything stopping us from having a single template file for each icon who’s parameters are set based on the state of the icon it is linked to.

For example, using the reference SVG javascript on The W3C Website. If the contents of colorlight.svg were:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" style="enable-background:new 0 0 64 64">
<defs>
      <ref id="paramFill" param="state" default="#dae1e4"/>
</defs>
  <g style="fill:#797878">
    <path d="m37.25 50h-10.5c-.55 0-1-.45-1-1 0-.55.45-1 1-1h10.5c.55 0 1 .45 1 1 0 .55-.45 1-1 1"/>
    <path d="m37.25 53h-10.5c-.55 0-1-.45-1-1 0-.55.45-1 1-1h10.5c.55 0 1 .45 1 1 0 .55-.45 1-1 1"/>
    <path d="m37.07 56h-10.14c-.65 0-1.18-.53-1.18-1.18 0-.45.37-.82.82-.82h10.85c.45 0 .82.37.82.82.01.65-.52 1.18-1.17 1.18"/>
    <path d="m32 60c2.21 0 4-1.34 4-3h-8c0 1.66 1.79 3 4 3"/>
  </g>
  <path d="m48 20.58c0-8.61-7.16-15.58-16-15.58s-16 6.97-16 15.58c0 2.73.72 5.29 1.98 7.51.77 1.49 1.32 2.56 1.67 3.23.72 1.4 1.14 2.21 1.66 3.42.22.51.55 1.28.86 2.16 1.23 3.49 1.7 6.82 1.7 6.82s.23 1.74 1.16 2.59c.26.24.52.38.65.44.45.21.86.25 1.11.25.16 0 .32 0 .48 0h4.66.13 4.66c.16 0 .32 0 .48 0 .24 0 .66-.04 1.11-.25.13-.06.39-.2.65-.44.93-.85 1.16-2.59 1.16-2.59s.47-3.33 1.7-6.82c.31-.88.64-1.65.86-2.16.52-1.21.94-2.02 1.66-3.42.35-.68.9-1.74 1.67-3.23 1.27-2.23 1.99-4.79 1.99-7.51" style="fill:url(#paramFill)"/>
<script xmlns="http://www.w3.org/2000/svg" type="text/ecmascript" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="ref.js"/>
</svg>

Then you’d be able dynamically set the colour of the bulb to whatever you’d like. OpenHAB’s UI can set this directly from the state, and convert this as a #color in the javascript file. This means we can get an icon loaded for every possible value, and only have one image on disk per icon type!

This should also be true for icons like battery and garagedoor, the position can be set dynamically also.

3 Likes
2

Hi Ben,

I had exactly this in mind when designing the IconProvider interface.
Currently, the ClassicIconProvider extends AbstractResourceIconProvider, which is an implementation that will simply check for appropriate resources that respect a certain naming scheme (taking the state into account).
It should be easily possible to implement an alternative IconProvider which comes with the appropriate SVG files and dynamically serves it with the according color/state parameter. Would be cool if you’d be willing to implement that and come up with a PR at ESH!

Regards,
Kai

1 Like
3

Thanks again Kai!

Quite honestly, I’m a beginner at this sort of stuff. But I’m more than willing to give it a go when I have the time to do so, if not just to see how far I get!

4

I’m loving this concept. I’d love to to see a “data quality” layer on icons. For example, when ThingStatusDetail is “COMMUNICATION_ERROR”, or if the value of another arbitrary Item indicates a problem I would love to be able to put a big red X over the icon or something like that. Unfortunately dynamic icons can currently only take the value of the current item into consideration, and don’t let you specify another item to use as you can with label and value colors.

5

Imho this would be a disjunct requirement - it would rather be an additional overlay or maybe a new feature on a widget (this info could be placed somewhere else on the widget as well).

For having such flexible widgets that take information from different sources (items, things, etc.), there is a discussion on a new kind of sitemaps that would support such stuff.

6

I started to look into this and I don’t think it would be wise to rely on the SVG Referenced Parameter Variables. Doing so would require additional changes in any UI wishing to support it, especially mobile apps (they need to add additional parameters, possibly download and run a javascript file, etc.). The UIs shouldn’t have to do ANYTHING different than they do now. It should just work. Not to mention that the SVG Parameters spec is still a draft that doesn’t appear to be fully supported.

I think a better alternative would be to better to create a custom namespace and add attributes to objects in a <def /> tag that the IconProvider can use to identify values that need altering. We would be able to slowly update the existing SVGs over time and the clients wouldn’t need to do anything.

1 Like
7

I was just reminded of this topic.
@Benjy, I would second @kabili207’s concerns. The correct SVG definition should be build on the server and only presented by the client.

Did any of you by any chance look into the needed modifications?

8

I finally decided to dig back into this, using XSLT to create the SVG files sent to the client. I’ve managed to create XSL files for all of the complex icons I could find in the ESH github (ie. icons that had more than an on/off state). So far that’s light/dimmablelight, humidity, battery, heating, cistern, sewerage, garagedoor, cinemascreen, blinds/rollershutter, and time.

I haven’t started work on the java code to actually do the transformations yet. I wanted to make sure I had the XSLT working properly first.

1 Like