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 <[hidden email]> 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 <[hidden email]> 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; [hidden email]; 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 <[hidden email]> wrote: > > > > > On 2018-11-03, at 4:24 PM, Chris Muller <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim > Don't compare floating point numbers solely for equality. > > > |
In reply to this post by Chris Muller-4
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'! 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 |
In reply to this post by Chris Muller-3
> On 2018-11-03, at 6:20 PM, Chris Muller <[hidden email]> wrote: > > Surefire way to reproduce: Weird. Tried that and simply can't replicate it. What platform are you using? tim -- tim Rowledge; [hidden email]; 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; [hidden email]; 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 <[hidden email]> wrote: > > Surefire way to reproduce: 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.
_,,,^..^,,,_ best, Eliot |
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 <[hidden email]> on behalf of Eliot Miranda <[hidden email]>
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 <[hidden email]> wrote:
> > Surefire way to reproduce: 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.
_,,,^..^,,,_
best, Eliot
|
Free forum by Nabble | Edit this page |