Heh, good old @BartButenaers - no patience what so ever But OK, let see what you have done and then figure out better solutions for sizing and positioning of that moving element.
Well the initial idea was quite simple: take your template node and convert it to a UI node. But the dynamically created radio buttons didn't want to fire the watch of the scope variable. Have been reading through 50% of Stackoverflow, but then I was tired of the AngularJs ng-model mystery and I decided to use simple click events. And that worked from the first time. No magic for me anymore
All of that could be built without radio element (forcibly hidden) usage. Just one internal state to manage. For ui_template it makes sense but for dedicated node ... hmm... can't we really do better?
When the node was almost done, I was thinking the same: why on earth am I using a radiobutton, because it is in fact hidden and I don't use anything from it anymore...
I went through hotNipi's original UI Template and got it working very well in a 5X wide group w/ 3 options.
On then 7" 800x480 official RaspberryPi TouchLCD Display, where my widget size is 24, I got the object taking up just one line.
Your multistate node takes up more than 1 line ... and enough CCS was overwritten to make the tweaked UI-template versions take up more than 1 line now as well.
I posted my code in the Multistate Flow that I shared, you can see the dimenstions I applied to make it fit nicely on the RaspberryPi official display...
None of this is criticism (you did absolutely awesome work)... just sharing the results of my testing....
Here is what they look line when they take up 1 line: (size 6x1 or 5x1)
This is what happens when the dimensions aren't correct, and you re trying to fit it into a 6x1 or 5x1 grid:
When adding your Node.. CSS settings affected my UI-Template nodes too.... they all require scroll bars to fit .
Your node is sized 25% larger than my UI-Template objects... So I had to increase my grid size to 32x32 (from 24x24). If you are using HotNipi's original work, they will be the larger... But remember that I re-sized his work so that it would fit comfortably in the default size often used on the RaspberryPI Official Display. A 32x32 grid size is too big on the Raspberry PI displays and really limits content.
I know I represent only a subset of users.... but I think this is as small as you need to plan for... 840x400 on a 7" screen.
As an aside, 24x24 grid with 4x4 for widget spacing also makes my graphics display very nicely on a cellular phone as well... with more than enough room to effectly issue commands with a touch... (it helps that cellular touch screens are often very precise and we've trained ourselves to use them carefully.... it's funny how instantly sloppy we become when using larger touch screen panels)...
Most of the default dashboard widgets don't support unit size 24x24 px. It is very extreme and requires to override many things to get useful results.
The unit size adjustment is not magic wand and definitely not last one and singe option to fit something into small screen.
Any node built for dashboard should and mostly do follow same standards and they behave on same rules. So I cant see why this node should support it by default. It is painful to do so. Believe me I have tried a lot.
Got a new template node from @hotNipi which was based on div elements instead of radio buttons. I have redesigned the UI node to use the same mechanism, so the code is now much cleaner.
Moreover I have converted the option's "value" field to a TypedInput, so it is now possible to use both strings and numbers:
BTW the current version has no rounded borders anymore. Will add soon a section on the readme page how to accomplish that, but need some assistance from my partner ...
A couple of issues I have found, apologies if they have already been noted, if one of the states is selected by numeric 0 then feeding that in does not select the state. It works ok with string "0".
Are you planning to add the optional message pass through checkbox, and the ability then to show state of input or output, as seen in the core switch node? I find that very useful, and the Show state of Input feature cannot be replicated with external nodes.