Hi Eliot and all,
I have just noticed in Squeak 5.2 that attempting to scroll a text pane beyond its scroll limit causes the text cursor to start moving. So, for example, when I have a selected expression in the debugger, and I simply scroll the text pane, I hit the end and lose the selection, which is incredibly annoying.
Does anyone know why this is and how to fix it?
Thanks
The bug doesn't exist in the 5.0-201807260206 VM. This affects the input events coming in, which manifests in ways no one can predict.
Honestly guys, we literally threw away all the months of accumulated confidence value from testing that VM. This software is too complex to safely release any other way than long test cycles. There isn't any extra cost to the "wait" approach, whereas slamming in untested code potentially costs a lot -- everybody now has broken binaries out there, and now we have to put out yet another release of 5.2. :( It's just not worth the risk... On Sat, Nov 3, 2018 at 4:45 PM Chris Muller ma.chris.m@gmail.com wrote:
Hi Eliot and all,
I have just noticed in Squeak 5.2 that attempting to scroll a text pane beyond its scroll limit causes the text cursor to start moving. So, for example, when I have a selected expression in the debugger, and I simply scroll the text pane, I hit the end and lose the selection, which is incredibly annoying.
Does anyone know why this is and how to fix it?
Thanks
On 2018-11-03, at 4:24 PM, Chris Muller asqueaker@gmail.com wrote:
The bug doesn't exist in the 5.0-201807260206 VM. This affects the input events coming in, which manifests in ways no one can predict.
I do't seem to be able to replicate this on a 5.2 image running on a 5.2 Pi vm.
Specifically Squeak5.2beta latest update: #18199 Current Change Set: Unnamed1 Image format 6521 (32 bit) & /home/pi/Squeak/sqcogspurlinuxhtRPi/lib/squeak/5.2-201810190412/squeak
I opened a debugger (with cmd-. just in case that might matter) and EventSensor>processEvent: selected some code near the top (event at: 8 put: window) and then scrolled down using the mouse wheel (Apple Mighty mouse). The selection was retained as I'd expect.
Do you have a good example I can try out?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't compare floating point numbers solely for equality.
Surefire way to reproduce:
1) launch Squeak5.2 or Squeak5.1 with the 5.0-201810190412 VM.
2) Click "Skip" to remove the "Welcome To Squeak" banner. The "Welcome To Squeak" window is there.
3) Click somewhere in the text pane to give it keyboard focus.
4) Click and drag to select 4 or 5 lines of text in the second paragraph.
5) Using mouse wheel, scroll down a few lines.
6) Using mouse wheel, scroll up *really fast*, ensuring to slam to the top. The selection is gone text cursor is one or more words to the left of the original selection.
7) If the selection is still there, keep scrolling up as fast/hard as you can, and watch the text cursor move in increments of one word to the left, as if Control+[Left Arrow] is being pressed.
- Chris
On Sat, Nov 3, 2018 at 7:27 PM tim Rowledge tim@rowledge.org wrote:
On 2018-11-03, at 4:24 PM, Chris Muller asqueaker@gmail.com wrote:
The bug doesn't exist in the 5.0-201807260206 VM. This affects the input events coming in, which manifests in ways no one can predict.
I do't seem to be able to replicate this on a 5.2 image running on a 5.2 Pi vm.
Specifically Squeak5.2beta latest update: #18199 Current Change Set: Unnamed1 Image format 6521 (32 bit) & /home/pi/Squeak/sqcogspurlinuxhtRPi/lib/squeak/5.2-201810190412/squeak
I opened a debugger (with cmd-. just in case that might matter) and EventSensor>processEvent: selected some code near the top (event at: 8 put: window) and then scrolled down using the mouse wheel (Apple Mighty mouse). The selection was retained as I'd expect.
Do you have a good example I can try out?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't compare floating point numbers solely for equality.
On 2018-11-03, at 6:20 PM, Chris Muller asqueaker@gmail.com wrote:
Surefire way to reproduce:
Weird. Tried that and simply can't replicate it. What platform are you using?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
Surefire way to reproduce:
Weird. Tried that and simply can't replicate it. What platform are you using?
Linux x64.
Give how little time there has been since the 20180726 VM, I hoped Eliot would have a good suspect for the cause based on his knowledge of the changes that went in since then, and my account of the symptom.
I've gone back to the 20180726 VM on my machines but, IMO, this seems significant enough to be worth fixing in the 5.2 release. We could simply revert to the VM we tested, 20180726.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
Hi Chris,
On Tue, Nov 6, 2018 at 4:44 PM Chris Muller asqueaker@gmail.com wrote:
Surefire way to reproduce:
Weird. Tried that and simply can't replicate it. What platform are you
using?
Linux x64.
Give how little time there has been since the 20180726 VM, I hoped Eliot would have a good suspect for the cause based on his knowledge of the changes that went in since then, and my account of the symptom.
I've gone back to the 20180726 VM on my machines but, IMO, this seems significant enough to be worth fixing in the 5.2 release. We could simply revert to the VM we tested, 20180726.
I'm n to Aware off any changes to event handling in X11 between those two VMs. Since the bug seems to be timing related it is not inconceivable that the issue iOS that the newer VM is faster and that hence the bug manifests because the newer VM is faster, not that it processes mouse wheel events any different. SO before we condemn the current VM can we please look for candidate changes and do some more careful analysis of the bug. So far we're identifying symptoms not causes, and until the bug is explained simply reverting the VM is not being objective.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
Hi,
I'm also on Linux-x64, experiencing the same issue. If I'm not missing something, it should boil down to this PR https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/155/files? and the fact that HandMorph>>filterEvent:for: only translate Ctrl+up/down, while passing on Ctrl+left/right as normal key events.
So the VM now generates Ctrl+left/right whenever you (accidentally) scroll horizontally, this moves the cursor by a word, which in turn instructs the text view to scroll back to the area where the cursor currently is.
Best, Tom
________________________________ From: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of Eliot Miranda eliot.miranda@gmail.com Sent: Wednesday, November 7, 2018 3:50 AM To: Chris Muller; The general-purpose Squeak developers list Subject: Re: [squeak-dev] VM sending keystrokes on mouse-wheel?
Hi Chris,
On Tue, Nov 6, 2018 at 4:44 PM Chris Muller <asqueaker@gmail.commailto:asqueaker@gmail.com> wrote:
Surefire way to reproduce:
Weird. Tried that and simply can't replicate it. What platform are you using?
Linux x64.
Give how little time there has been since the 20180726 VM, I hoped Eliot would have a good suspect for the cause based on his knowledge of the changes that went in since then, and my account of the symptom.
I've gone back to the 20180726 VM on my machines but, IMO, this seems significant enough to be worth fixing in the 5.2 release. We could simply revert to the VM we tested, 20180726.
I'm n to Aware off any changes to event handling in X11 between those two VMs. Since the bug seems to be timing related it is not inconceivable that the issue iOS that the newer VM is faster and that hence the bug manifests because the newer VM is faster, not that it processes mouse wheel events any different. SO before we condemn the current VM can we please look for candidate changes and do some more careful analysis of the bug. So far we're identifying symptoms not causes, and until the bug is explained simply reverting the VM is not being objective.
tim
tim Rowledge; tim@rowledge.orgmailto:tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
-- _,,,^..^,,,_ best, Eliot
Hi Tom, Hi Chris,
see commit d964e7 which has the X11 code do the same as the iOS code. I'd love it if someone who knows Windows would test the same thing there-on. Also, are the "#ifndef NO_WHEEL_MOUSE" defines necessary (eg perhaps required for WINCE) ? It would be lovely just to include the code unadorned by the noise, or to use something less tacky such as "#if defined(WM_MOUSEWHEEL)". Chris, can you see if this fixes your issue?
On Tue, Nov 6, 2018 at 7:16 PM Beckmann, Tom < Tom.Beckmann@student.hpi.uni-potsdam.de> wrote:
Hi,
I'm also on Linux-x64, experiencing the same issue. If I'm not missing something, it should boil down to this PR https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/155/files%E2%80%8B and the fact that HandMorph>>filterEvent:for: only translate Ctrl+up/down, while passing on Ctrl+left/right as normal key events.
So the VM now generates Ctrl+left/right whenever you (accidentally) scroll horizontally, this moves the cursor by a word, which in turn instructs the text view to scroll back to the area where the cursor currently is.
Best, Tom
*From:* Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org on behalf of Eliot Miranda eliot.miranda@gmail.com *Sent:* Wednesday, November 7, 2018 3:50 AM *To:* Chris Muller; The general-purpose Squeak developers list *Subject:* Re: [squeak-dev] VM sending keystrokes on mouse-wheel?
Hi Chris,
On Tue, Nov 6, 2018 at 4:44 PM Chris Muller asqueaker@gmail.com wrote:
Surefire way to reproduce:
Weird. Tried that and simply can't replicate it. What platform are you
using?
Linux x64.
Give how little time there has been since the 20180726 VM, I hoped Eliot would have a good suspect for the cause based on his knowledge of the changes that went in since then, and my account of the symptom.
I've gone back to the 20180726 VM on my machines but, IMO, this seems significant enough to be worth fixing in the 5.2 release. We could simply revert to the VM we tested, 20180726.
I'm n to Aware off any changes to event handling in X11 between those two VMs. Since the bug seems to be timing related it is not inconceivable that the issue iOS that the newer VM is faster and that hence the bug manifests because the newer VM is faster, not that it processes mouse wheel events any different. SO before we condemn the current VM can we please look for candidate changes and do some more careful analysis of the bug. So far we're identifying symptoms not causes, and until the bug is explained simply reverting the VM is not being objective.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Breakthrough: It finally booted on the first try.
-- _,,,^..^,,,_ best, Eliot
Not sure if this is the same, but it sounds similar to something I have experienced in recent squeaks. See if this helps at all:
'From Squeak5.1 of 23 August 2016 [latest update: #16548] on 3 November 2018 at 9:50:50 pm'!
!TextMorphForEditView methodsFor: 'event handling' stamp: 'raa 11/3/2018 21:50'! keyStroke: evt | view | editView deleteBalloon. (editView scrollByKeyboard: evt) ifTrue: [^self].
[(evt controlKeyPressed and: [evt commandKeyPressed] and: [evt keyValue = 28 or: [evt keyValue = 29]] ) ifTrue: [ ^self "funky trackpad code scrolls - yecch" ].] on: Error do: [ :ex | ].
self editor model: editView model. "For evaluateSelection" view := editView. "Copy into temp for case of a self-mutating doit" (acceptOnCR and: [evt keyCharacter = Character cr]) ifTrue: [^ self editor accept]. super keyStroke: evt. view scrollSelectionIntoView.
"Make a cheap check and guess editing. (Alternative would be to copy the old contents and then compare them against the new ones. Maybe add a better hook in the TextEditor." (self readOnly not and: [evt keyCharacter isAlphaNumeric or: [evt keyCharacter isSeparator]]) ifTrue: [view textEdited: self contents].! !
On 11/3/18 5:44 PM, Chris Muller wrote:
Hi Eliot and all,
I have just noticed in Squeak 5.2 that attempting to scroll a text pane beyond its scroll limit causes the text cursor to start moving. So, for example, when I have a selected expression in the debugger, and I simply scroll the text pane, I hit the end and lose the selection, which is incredibly annoying.
Does anyone know why this is and how to fix it?
Thanks
squeak-dev@lists.squeakfoundation.org
-
Beckmann, Tom -
Bob Arning -
Chris Muller -
Chris Muller -
Eliot Miranda -
tim Rowledge