Re: [etoys-dev] Keyboard support
Ricardo Moran <[email protected]>
| Newsgroups | gmane.comp.lang.smalltalk.squeak.squeakland |
|---|---|
| Message-ID | <CALr=5n0Qmpzwom_ROpBjBBgdbdMGxu4AHOe4ES9rDfCm2YSCLQ@mail.gmail.com> |
2012/2/17 K. K. Subramaniam <[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). > Yes, that happens to me also (in windows). I think that is a limitation of the arrow keys, it works when using the WASD keys. > > 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. > Yes, I agree with these last three ideas. > * The stringmorph "Key:" is superfluous. It comes in the way of grouping > keys > into a panel. This could be dropped. > I'm not sure about this one, though. I know it doesn't add any information but I think the "Key:" serves as a title and a grabbing area for the morph. If others agree with you, I'll drop it. > * 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. > You're right, actually there is no point in having a "keyButton" instance variable. Thanks, I'll fix these things. Richo > > HTH .. Subbu > _______________________________________________ squeakland mailing list [email protected] http://lists.squeakland.org/mailman/listinfo/squeakland