Feature Request - Off - Auto - On Toggle

No I'm not fast. I'v seen fast codding. I'm slow as the snail.
But there is other therms in coding like reliability, compatibility, openness, future-proof, reason-ability, readability, learnability etc. Those make much more sense than speed. And I fail most of the time with most of the therms I used here :smiley:
But the perfect world is still too far to reach so let's keep going.

Thank you :slight_smile:

1 Like

I created a flow featuring these nodes. It's here.

Multi-State Toggle Examples using UI-Template and CCS Overrides

Full credit is given to user hotNipi.

image_2021-02-15_133534

1 Like

Next challenge - vertical 2 column layout for 8-way with option to disable couple of them with incoming msg

Years ago... I was doing some CompactLogix PLC programming and WonderWare Intouch Development for a Waste Water Treatment facility in a factory. I had one vessel, called the reactor, where we had 7 phases (actions is a better word) defined to perform batch processing or alternative routing... Literally... Collect, Transfer, Treat, Recirc, Divert, Discharge, Standby. (some of these phases were elaborate multi-step processes too.... Treat could have been broken up into additional Phases)...

Actually much better challenge
image
As I was lazy enough the sliding element position is percentage driven. (Of course you can fine-tune it)
But as you can see it starts to fail for a) wider layouts, b) when count of choices rises.

So it can have better solution. :slight_smile:

Hey guys,
I have announced here a first beta version.

We can do that in the near future, but I will be some time away from Node-RED soon, so will have to wait some time...

I thought I'd show you all my first implementation of the Multi-State UI-Template based Toggle Switch in a hobby project that I have. (Sonoran Desert Fish Nook YAAK - yet another aquarium controller). The NodeRED project is running in Kiosk Mode on the small 7" touch display. More than adequate to touch the toggle and move it accurately..

(ignore the fact that my Conductivity is reading zero... probe was accidently dropped and fully submerged in water...)

I also experimented with a bit more CSS overriding with the UITemplets to control Font Size and Header Spacing on the Groups (known as cards). I made this a global change on the project, so that I get a better fit for the content on the Raspberry Pi Official 800x480 LCD Touch Display this way...

5 Likes

I understand. There are a few dashboard nodes that don't play nice and do require me to either use AUTO or a 2 height grid. I can live with that. It's actually a very small number of dashboard nodes that give me grief. Some things like Tab/Group/Menu font sizes, padding, spacing, etc.. I control with a Dashboard Override script so that it plays very nice on smaller displays.

I switched to 48x48 for the 1x1 widget size... No way.... Can't get any amount of content on the screen.

I'm able to fit yours on 1 line if I mess with the height CCS property in the UI template used for the rounded corners... just the .wrapper.. 18 is about right. although I wish the Option Text would center better...

.multistate-switch-wrapper{ border-radius:15px; height:18px; } .multistate-switch-slider{ border-radius:15px; }

NewMultiStateNode

@SonoraTechnical I've moved the above post here to keep the subject matter together and provide context to your post.
Your issue is an edge case, as you are trying to use dashboard elements, whether it be the ui-template or the contrib node, in a very small widget size, whilst the other topic is about developing a new node.

Please lets confine this discussion here if possible.
Thanks.

Simply made mention of my 'edge case' so that as they were developing the node.. they might expose a few properties that would allow brave souls to better implement it on very small displays. i suspect there are a fair number of node-red users deploying on rpi.. and then a fair number of those using the official rpi display with it's small size and limited resolution.

it's fine. developers of the node are free to ignore any suggestions I might have about useability on small displays. i'll stick with home grown ui-template versions where I have better control and stay out of the way of the professionals. :wink:

(Perhaps in the not so distant future RPiF will release a new official 8" display (same footprint as current 7" minus the huge bezels) that supports 1920x1080... and then all of this custom scaling becomes moot.)

To cover one edge case makes all other edge cases cry. And there is many of such. Always.
Brave souls fork the repo and do what is needed to cover their edge cases. :wink:

Both developers are subscribed to this thread already, and will see whatever you post, and take your comments into consideration, helping if they can.

Moving your post, was not to undermine your comments, but to keep this topic in one place, making it easier to understand the full context of your issue, and also other forum users who may have the same problem in the future.

meh! I can force Bart's multiswitch node to play nice with my 1/2 of default scaling and accept the odd text alignment as a consequence.
I'll stick those ccs overrides in the node that I use for doing all of my overrides... it's easy to manage... no worries.

how is it at 28px high ? (and of course the height and width can be different if you want/need)

Yeah, looked at the image of your solution .
I'd do couple of small changes.
Get rid of top bar and side bar. (navigation between tabs can be done with buttons and thet can be 1x1 with icon )
Change font to and font size.
As for now quite of space is freed, id go for bigger unit size.

I have 8'' tablet and All of that fits perfectly with 35x35 unit size
Of course there is not much "air" but I'm bad with the art also so it is what it is.

1 Like

32x32 was the point that it started looking better... But even at 24x24.. the new multiswitch node is very useable.

Honestly, the only dashboard node that I truly have issues with at 24x24 is the ui-led. which is funny, because it would seem as if that node would be the most flexible, especially if you don't use any glow/shadow effects.

All other dashboard nodes render fine. I might explore taking my whole project to 32x32... it's a bit of a 'refactoring' of sorts for the entire visual presentation, but might be worth it to eliminate struggling with two dashboard nodes that I like very much (the new ui-multi-switch node is quite good and of course the above mentioned ui-led.)

I do like the side nav menu... and just need to explore the ccs overrides to make that guy a bit narrower...

there is an option to just show icons of course... Is that narrow enough ?

I'm already doing that and it looks great at 24x24!
if I go to 32x32...I may work to get it just a bit narrower... as it will grow 25% wider...

It's a good exercise to become familiar with the basic CCS properties that dashboard uses... just to make small adjustements here and there..... the adjustments I made to the Group Name display (font sizes/padding) was great as that takes up a TON of unnecessary room..

Impressive amount of content. I imagine your 8" tablet is somewhat high resolution?

Hopefully the next RaspberryPI official touch display grows to at least 1280x720... though 1920x1080 would be fantastic.

Thank you for sharing the suggestions. I am giving thought to at least going 32x32 as that helps me maintain most of my content... with just a small number of objects migrating to another screen.

Would you mind posting these changes, also trying to squeeze a lot into a small space :wink: