-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Limitation of UIFORM: only responsive to touch (release) and not (press) #378
Comments
Added links to the code. I note that this would break all apps unless you make press optional, as in |
yes, that was the idea. I wasn't aware that uiform-register would be used outside uiform.scm, but since it is a publicly defined function it is not excluded. so the optional press is better |
looking at lambdanative/modules/uiform/uiform.scm Line 1887 in 04195af
it might actually need also a third input for the slider to smoothly work |
It is documented at https://github.com/part-cw/lambdanative/wiki/Index-of-Module-uiform and also it doesn't include a : which would indicate it would be a private function? |
Well once you have optional arguments you can have as many as you want. We could also name them like (make-list n #!optional (elem 0)) so it is clear what they are and what their default is? What is the third argument you want - the event type? |
We call this in directly in some lnhealth (uiform) apps to register new widgets. Also, consider uiform-register-legacy which can be used to register existing ln_glgui widgets in uiform in order to use them there. See #258. |
By design the module UIFORM is only responsive to touch (release) events but not to touch (press) events.
This has a few limitations in the user interactions, notably buttons do not change colour upon press or the slider does not move until the finger is released.
If there is larger interest in this, we could check whether redefining (uiform-register name draw input) to
(uiform-register name draw release press)
would make sense?Another, slightly related feature that affects all fields would be the possibility to pre-assign an active field without user input first (i.e. cursor placed in a text field and keyboard open upon load)
The text was updated successfully, but these errors were encountered: