Re: [etoys-dev] Keyboard support

"K. K. Subramaniam" <[email protected]>
Newsgroups gmane.comp.lang.smalltalk.squeak.squeakland
Message-ID <[email protected]>
On Friday 17 Feb 2012 1:35:38 AM Ricardo Moran wrote:
> It's now a single-key morph and it compares the keyStrings (I don't know if
> this is good or bad). I hope it works across platforms (even if you have to
> reconfigure the keys when you open the project). I only have windows here
> so I would appreciate if someone can tell me if this works on Linux and
> Mac.
I tried it on Linux (Kubuntu 10.04). Single and double key presses work as 
expected. But third and further keys are ignored (i.e. up+left+right acts as 
up+left instead of up).

KeyPressMorph gets my vote. It has awesome implications for interactive 
projects on handhelds and smartphone form factors. Thank you, Ricardo.

A few observations:

* apart from just isPressed state, could you also track timePressed? Authors 
can use longPress etc. for driving interaction. A key can also be used as an 
analog input (e.g. acceleration). Note that isPressed == (timePressed  > 0).
* If a user presses the button area accidentally, there is no way to escape 
out of it. How about clicking the button or the floating tip to cancel the 
operation?
* The tip "Press a key" is confusing. Suggest changing it to "Press new key" 
or similar and perhaps use blink or color change to indicate modal status.
* The stringmorph "Key:" is superfluous. It comes in the way of grouping keys 
into a panel. This could be dropped.
* A new key is not initialized with a label. If a new key is initialized with 
'a' label, 'currentKey != nil' becomes invariant. the check for nil in 
currentKey could be replaced with an assert or dropped.

HTH .. Subbu
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.