Photon Micro GUI

TBH i do not have much experience with Tcl itself outside of writing a few Tk utilities to automate a few bits on my job some years ago. I followed its approach mainly because it sounded like a good combination for being very simple to implement and very flexible to work with, making it ideal for a hosted scripting language (though it doesn't fit all tasks - far from it, especially in places you want even a hint of performance).

So i can't really judge how exactly it differs from Tcl language-wise. It is not compatible as it provides much fewer functions and those work in a different manner. For example there isn't uplevel, but there is upeval which works in a similar manner (though the depth is always one but they can be nested) and there is also downeval (used through upeval to evaluate code back at the environment from where upeval was called), topeval (like upeval but at the toplevel environment), enveval (eval in a function-like environment with optional variable passing in and out) and jaileval (eval in a new, optionally clean, LIL context). Also there isn't much in terms of state notification outside of watch (which i think it works like Tcl's trace but only for variable writes).

I think the syntax is compatible with Tcl (i haven't done any excessive testing to be sure though, LIL was done mainly by "eyeballing" Tcl) so it could be possible to write shims in LIL to be able to write code that works in both, but TBH i wouldn't rely on that.

So i call it just "Tcl-like" in the same sense that JavaScript is a C-like language.

In your first example, you've just made a knob that doesn't look like a knob.

In your second example, you're confusing mouse position and gesture. Linear sliders map mouse position to state changes, rotaries map gesture. Another way of looking at it is that a rotary slider's state is decoupled from the input, and in doing so, is a much more responsive control. Not to mention, you have an infinite 2D area to traverse to change the knob value with respect to the widget itself, not a finite, defined path.

And the huge reason that linear sliders (at least off the shelf ones) are impossible to use for audio UIs is that 99% of your user's time is spent adjusting from the previous position, not resetting it to a new one. That means any behavior where a click resets the position (like clicking just past the current position) is broken. Not just because it's trash UX for the application, but because in audio systems jumping parameter values can cause artifacts, and mitigating them is not without cost in performance and fidelity.

If they can already do it for such distinct devices as Mac, iPhone, iPad, TV and Watch, there's no reason it can' be adapted for Windows, Linux and Android as well.

This is something that should have happened 5 years ago, before Electron etc. had a chance to fill in a obviously much-needed need.

Really, why do we need anything more than "Button" to describe a button, or "List" to describe a list, on any GUI? HTML solved this a trillion years ago, it's a wonder it took so long to be wholeheartedly adopted for native UIs. I know Microsoft tried with WPF/XAML but it didn't seem to catch on.

Gestures?