I’d say a better solution is not to use buttons for something like this - mostly due to the way they hungrily consume input. Here’s what I’ve got:
It’d take too many screenshots so here’s the project:
And a quick top-down behind the concept:
- each handle is a separate user widget with its own logic; so you can have more than 2 handles if needed
- handles sit in the parent’s canvas and we manipulate the position of the slots the canvas creates
- the handles tell the parent they’ve been selected and the parent’s onMouseMove shifts them about, dictating clamp values based on its own geometry and the geometry of the moving children
- nothing here is hardcoded so the handles can be of any size and padding is accounted for [fingers crossed]
- each handle displays its own value and the one being moved appears on top of the other one
- disclaimer: this has not been tested thoroughly
- one thing that I omitted knowingly is the offset of where the cursor holds a handle; mostly irrelevant if the handle is thin, and quite noticeable when its thick, as in the anim
- a feature that is missing and will probably be quite relevant is that each handle should respect the position of the other and treat its offset as a clamp. So the right one should not be allowed to slide in front of the left. You could flag each handles with a bool so it know where it belongs and onMouseMove can dictate clamping values accordingly.
Hopefully you can take it apart or at least treat it as inspiration. There are some kinks to iron out but it seems to be the right direction to take. There’s a bit of config available:
What happens to those values is unhandled atm; they are stored in the handles and their parent has access, ofc. They can be dispatched or the parent can pull them. Up to you.