[Vm-dev] Multiple Keydown and up

Marcel Taeumel marcel.taeumel at hpi.de
Thu Jan 7 10:09:18 UTC 2021


Hi Nicolas.

> why does it bother you?
> To me they are not at the same level.

Exactly. The user pushes a key and gets a single keyDown. Repetition is (IMO) only defined in terms of keystrokes where characters matter. There is only a single mouseDown while the user keeps on holding the mouse button. Why the difference? =)

Here are possible options:
A) Only send a single keyDown even if the users holds the key
B) Keep on sending mouseDown while the user holds the button

I am asking for "more" consistency and a (maybe) simpler mental model.

Anyway. It's good enough as it is now. At least for the Windows platform.

Best,
Marcel
Am 07.01.2021 10:41:58 schrieb Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:

Le jeu. 7 janv. 2021 à 09:20, Marcel Taeumel a écrit :
>
>
> Hi all!
>
> Here are some related issues to check:
>
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/42
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/43 (closed)
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/363
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/396
> https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/456
>
> On Win10, it only bothers me that there is a keyDown for every keystroke. The rest seems fine.

Hi Marcel,
why does it bother you?
To me they are not at the same level.
Either you express interest in low level events (keydown/keyup), say
for a space invader game, and in this case, most certainly ignore the
synthetic/composite/interpreted keystroke.
Or you express interest in higher level events (keystroke) like for
textual input.
So my POV is that they should co-exist, it's application business to
select whichever is relevant.

>
> For example, [CMD]+[SHIFT]+[s] yields this:
>
> [1891 at 534 keyDown (18) 288897400]
> [1891 at 534 keyDown (16) 288897478]
> [1891 at 534 keyDown (83) 288897556]
> [1891 at 534 keystroke '' (83) 288897556]
> [1891 at 534 keyUp (16) 288897619]
> [1891 at 534 keyUp (18) 288897634]
> [1891 at 534 keyUp (83) 288897634]
>
> Looks good :-)
>
> Best,
> Marcel
>
> Am 06.01.2021 22:38:58 schrieb David T. Lewis :
>
>
> On Wed, Jan 06, 2021 at 04:27:45PM -0500, David T. Lewis wrote:
> >
> > On Tue, Jan 05, 2021 at 09:22:58PM -0800, tim Rowledge wrote:
> > >
> > >
> > >
> > > > On 2021-01-05, at 6:54 PM, Yoshiki Ohshima wrote:
> > > >
> > > > Hi,
> > > >
> > > > Another Raspberry Pi Scratch issue report but possibly affects Squeak on other platforms.
> > > >
> > > > A user reported that if you press down one key, and then another key, and then try to release both keys, the key up for the first key does not get reported.
> > > >
> > > > https://youtu.be/N9q8DxYWAik
> > > >
> > > > It could be the way Scratch handles them, but maybe it is an VM issue. Can somebody give me insight?\
> > >
> > > It depends; is this the NuScratch as delivered in Raspbian? Or the package loaded into a post 5.1 image?
> > >
> > > In experiments updating to a 5.3 image I notice that the keyboard listener
> > > I wroet way back when no longer seems to work as well. I do recall Marcel
> > > doing work in that general area and changing how events are dealt with;
> > > I'm guessing it will be related.
> > >
> > > Scratch expects to see a state for each key, rather than handle events - in
> > > *some* places. Sigh. Anything that makes the KeyboardStateWatcher class not
> > > accurately track the key events will mess up some things. Or indeed, if I
> > > made any mistakes or failed to catch every possible case, which must be
> > > possible.
> > >
> >
> > I'm sorry I cannot provide a reference, but I think that I recall some
> > discussion of this in earlier years. It may be that this was caused by
> > a limitation related to X11 key event delivery in the Unix VM. Possibly
> > there is some discussion in the vm-dev archives. That's all I remember
> > and it might be wrong.
> >
>
> Ugh, so as soon as I hit I think of looking in the old Mantis
> issue tracker. Here is the issue that I was remembering:
>
> http://bugs.squeak.org/view.php?id=7597
>
> So it was a Unix VM bug that apparently got fixed in Cog. I am not sure
> if this is same problem that we see today, but if so perhaps it is a
> regression.
>
> Note that the Mantis bug report includes HandMorph-handleEvent.st from
> Matthew Fulmer that might be helpful in debugging the problem today.
>
> Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20210107/bc82f847/attachment.html>


More information about the Vm-dev mailing list