New feature: globally provisioned widgets (i.e. with OSGi bundles)

Hi @Kai, nice to see some feedback from you - it’s a fresh new feature, my approach was to put it out there maybe a bit boldly as an experiment, and discuss the design afterwards; it’s not too late to make adjustments while there aren’t any widgets making use of it.

The reason was indeed to improve the visibility of some of the great widgets that are already out there, notably those tied to particular hardware or a particular binding (Netatmo, Ecobee, Nuki lock, Onkyo, Hue, Russound, Weather… just to name a few), people using this hardware or these bindings as well as HABPanel might be interested in them but don’t know they exist. They should IMHO be presented to the user and installed very easily or even automatically if possible. Moreover, some of those widgets use external resources (CSS, JS, images, icons…), usually there are instructions provided to put them in conf/html/etc so they’re accessible at static/etc - this is too complex; a bundle automating everything is way easier.

I had the idea to allow certain bindings to optionally (un)provision the widgets at their leisure if they detect HABPanel (for instance only when adding a new Thing of a certain type), so honestly I must say I feel a bit dirty with my solution, but the goal was to keep things simple and avoid at all costs a dependency to the HABPanel bundle, which wouldn’t make sense in this case. Then I realized bindings themselves should perhaps not deal with particular UI concerns at all :slight_smile:

This is very interesting and would indeed probably be enough, I didn’t think it was possible to scan other bundles like you suggest. I also agree with your concern about the “pollution” of the URL namespace with arbitrary mappings by widget bundles, those mappings (as well as the registration of the widgets themselves) should be properly handled centrally. I’ll have to wrap my head around all this - I’m naturally open to further suggestions.

Didn’t realize this either… Thanks for pointing that out. The icon sets are great for providing an item’s state and get the right icon in return, but of course other solutions would work too.