swiss-army-knife-card icon indicating copy to clipboard operation
swiss-army-knife-card copied to clipboard

Add Lock Tool

Open AmoebeLabs opened this issue 2 years ago • 0 comments

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:

  • 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!

AmoebeLabs avatar Jul 01 '22 11:07 AmoebeLabs