The versatile custom Swiss Army Knife card for Home Assistant allows you to create your unique visualization using several graphical tools, styling options and animations.
All the tools that support user interaction respond directly to that user interaction. In most cases that is fine, but in some cases, a single - accidental - tap can have unwanted consequences.
It would be nice to be able to 'lock' those tools, where the 'lock' must be removed first, before the tool can be tapped!
Additional background:
Related Issues (if any)
(Optional): Suggested Solution
User action is based on the top HTML/SVG element to respond to user interactions.
One could overlay a tool with this Lock Tool that handles the user interactions first:
The lock tool needs a - configurable - amount of taps, before it unlocks
After it unlocks, it stays unlocked for a configurable amount of seconds
Configuration:
The lock tool can be created with a RectEx, ie from square to a circle to "overlay" any other tools or even the complete card
Color and transparency can be specified. It can be styled just as any other tool!
The number of times the tool must be tapped, before unlocking
It has some Icon that can change depending on the state of the Lock Tool:
green for unlocked with an unlocked icon
yellow for almost unlocked (next tap unlocks tool!!)
red for locked
Position and size of the Icon can be specified, just like the Icon tool...
It will be a multi-part tool, just like the slider, switch, etc.
Visualization:
Visualization can already be made with existing tools, but the tap interaction can't be done yet
(Optional): Alternative Solutions
What if an extra user_action can be specified, that implements the above behavior?
The only problem then is that we are missing a state for the lock, as the tool must respond to that state to allow tap actions to pass, instead of blocking them. Same for the Icon that displays a lock/unlock state with colors.
Maybe the extra user_action is a good idea to handle the tap events! In that way, one can specify some stuff. In a later stadium, that could enable the implementation of other unlock strategies, such as long-press (which I hate BTW!!!!!)
As we can have multiple of these Lock tools per card, it needs to store its state!
The Problem To Be Solved
All the tools that support user interaction respond directly to that user interaction. In most cases that is fine, but in some cases, a single - accidental - tap can have unwanted consequences.
It would be nice to be able to 'lock' those tools, where the 'lock' must be removed first, before the tool can be tapped!
Additional background:
Related Issues (if any)
(Optional): Suggested Solution
User action is based on the top HTML/SVG element to respond to user interactions.
One could overlay a tool with this Lock Tool that handles the user interactions first:
Configuration:
It will be a multi-part tool, just like the slider, switch, etc.
Visualization:
(Optional): Alternative Solutions
What if an extra
user_actioncan be specified, that implements the above behavior? The only problem then is that we are missing a state for the lock, as the tool must respond to that state to allow tap actions to pass, instead of blocking them. Same for the Icon that displays a lock/unlock state with colors.Maybe the extra
user_actionis a good idea to handle the tap events! In that way, one can specify some stuff. In a later stadium, that could enable the implementation of other unlock strategies, such as long-press (which I hate BTW!!!!!)As we can have multiple of these Lock tools per card, it needs to store its state!