part-cw / lambdanative

LambdaNative is a cross-platform development environment written in Scheme, supporting Android, iOS, BlackBerry 10, OS X, Linux, Windows, OpenBSD, NetBSD, FreeBSD and OpenWrt.

Home Page:http://www.lambdanative.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Limitation of UIFORM: only responsive to touch (release) and not (press)

karliwalti opened this issue · comments

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)

Added links to the code. I note that this would break all apps unless you make press optional, as in (uiform-register name draw release . press) and assume that release == input is valid in all other cases?

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

((and (fx= type EVENT_MOTION) old) ;; drag

it might actually need also a third input for the slider to smoothly work

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

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?

it might actually need also a third input for the slider to smoothly work

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.