Multiple Keydown and up
Locked
 
|
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. It could be the way Scratch handles them, but maybe it is an VM issue. Can somebody give me insight? Thank you! -- Yoshiki |
|
|
> On 2021-01-05, at 6:54 PM, Yoshiki Ohshima <[hidden email]> 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. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: KFP: Kindle Fire in Printer |
|
|
On Tue, Jan 05, 2021 at 09:22:58PM -0800, tim Rowledge wrote: > > > > > On 2021-01-05, at 6:54 PM, Yoshiki Ohshima <[hidden email]> 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. Dave |
|
|
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 <[hidden email]> 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 <send> 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 |
|
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. For example, [CMD]+[SHIFT]+[s] yields this: [1891@534 keyDown (18) 288897400] [1891@534 keyDown (16) 288897478] [1891@534 keyDown (83) 288897556] [1891@534 keystroke '<Cmd-S>' (83) 288897556] [1891@534 keyUp (16) 288897619] [1891@534 keyUp (18) 288897634] [1891@534 keyUp (83) 288897634] Looks good :-) Best, Marcel
|
|
|
Le jeu. 7 janv. 2021 à 09:20, Marcel Taeumel <[hidden email]> 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@534 keyDown (18) 288897400] > [1891@534 keyDown (16) 288897478] > [1891@534 keyDown (83) 288897556] > [1891@534 keystroke '<Cmd-S>' (83) 288897556] > [1891@534 keyUp (16) 288897619] > [1891@534 keyUp (18) 288897634] > [1891@534 keyUp (83) 288897634] > > Looks good :-) > > Best, > Marcel > > Am 06.01.2021 22:38:58 schrieb David T. Lewis <[hidden email]>: > > > 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 |
|
|
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
|
|
|
Le jeu. 7 janv. 2021 à 11:09, Marcel Taeumel <[hidden email]> a écrit : > > > 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 > Ah OK, so the example that you provided looks good as you said, it's only the case of repetitions that bothers you (issue #42). I agree, but we cannot do much about it, it's the OS (windows) which send multiple WM_KEYDOWN. Microsoft recommand handling the "control" key events with WM_KEYDOWN (control keys are for example a shortcut for a menu or things like that, as opposed to textual input which should better use WM_CHAR). Maybe they wanted a repetition feature on control keys too? Who knows... > Am 07.01.2021 10:41:58 schrieb Nicolas Cellier <[hidden email]>: > > > 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@534 keyDown (18) 288897400] > > [1891@534 keyDown (16) 288897478] > > [1891@534 keyDown (83) 288897556] > > [1891@534 keystroke '' (83) 288897556] > > [1891@534 keyUp (16) 288897619] > > [1891@534 keyUp (18) 288897634] > > [1891@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 |
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |