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
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.