Smalltalk › Squeak › Squeak - Dev

Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

7 messages Options

Christoph Thiede

Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

Hi,

I will quote the bug report from here
<https://github.com/MrModder/Autocompletion/pull/25#issuecomment-513546349>
:

> - Open a workspace window, enter some text
> - press shift+left once
> - set the keyboard focus to another window
> - bring focus back to the Workspace
> - press shift+left once again
> Instead of selecting two characters, zero characters will be selected

The reason is in PluggableTextMorph>>#mouseEnter:, where the following is
done:
...textMorph editor selectInterval: selectionInterval...
As the selectionInterval is always positive, this operation destroys any
editor state where pointIndex < markIndex.

I just disabled this section in my image, and in a rush, I could not find
out what is missing. What has been the purpose of this snippet?
I also see this might be a debatable behavior: On the one hand, the user
might be irritated when he is returning to a textmorph after a long time,
trying to extend the selection with <shift>Arrow right but the selection is
shrinked indead. On the other hand, I have activated the
#mouseOverForKeyboardFocus setting (which is basically genius) and find it
annoying that the selection behavior changes after repositioning your mouse.
Has this ever been debated before?

I would welcome your opinions!

Best,
Christoph

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!

marcel.taeumel

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

Hi Christoph,

it might be possible to get rid of "selectionInterval" in PluggableTextMorph. This depends on the actual lifespan of the internal text editor in PluggableTextMorph. See #releaseEditor and #releaseParagraph in TextMorph. Regular text morphs (i.e. 'Hello' asText asMorph) do not preserve editor and selection on #mouseLeave:.

When working at text undo in TextEditor, I suspected that the editors in PluggableTextMorph live enough for that use case. So I did not add an extra inst-var for that.

We could try remove that "selectionInterval" variable and see what happens. I recall that at least keeping the selection stable after PluggableTextMorph >> #setText: is a good idea. At least then, both paragraph and editor will get replaced.

Note that selection affects scrolling for longer texts. If we lose selection at the wrong place, that big scroll field would just jump to the top again -- even if just changing a single character in that long text.

Best,

Marcel

Am 02.08.2019 18:37:11 schrieb Christoph Thiede <[hidden email]>:
Hi,

I will quote the bug report from here

:

> - Open a workspace window, enter some text
> - press shift+left once
> - set the keyboard focus to another window
> - bring focus back to the Workspace
> - press shift+left once again
> Instead of selecting two characters, zero characters will be selected

The reason is in PluggableTextMorph>>#mouseEnter:, where the following is
done:
...textMorph editor selectInterval: selectionInterval...
As the selectionInterval is always positive, this operation destroys any
editor state where pointIndex <>

I just disabled this section in my image, and in a rush, I could not find
out what is missing. What has been the purpose of this snippet?
I also see this might be a debatable behavior: On the one hand, the user
might be irritated when he is returning to a textmorph after a long time,
trying to extend the selection with Arrow right but the selection is
shrinked indead. On the other hand, I have activated the
#mouseOverForKeyboardFocus setting (which is basically genius) and find it
annoying that the selection behavior changes after repositioning your mouse.
Has this ever been debated before?

I would welcome your opinions!

Best,
Christoph

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Chris Muller-3

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

In reply to this post by Christoph Thiede

I would suggest avoiding the issue entirely, and turbo-charge your IDE at the same time with the following settings:

mouseOverForKeyboardFocus --> enabled

Windows Contents' Are Always Active --> enabled

Windows Controls' Are Always Active --> disabled

It separates window layering from focus, and makes everything "live". Once used to, it's nearly impossible to go back.

- Chris

On Fri, Aug 2, 2019 at 11:37 AM Christoph Thiede <[hidden email]> wrote:

Hi,

I will quote the bug report from here
<https://github.com/MrModder/Autocompletion/pull/25#issuecomment-513546349>
:

> - Open a workspace window, enter some text
> - press shift+left once
> - set the keyboard focus to another window
> - bring focus back to the Workspace
> - press shift+left once again
> Instead of selecting two characters, zero characters will be selected

The reason is in PluggableTextMorph>>#mouseEnter:, where the following is
done:
...textMorph editor selectInterval: selectionInterval...
As the selectionInterval is always positive, this operation destroys any
editor state where pointIndex < markIndex.

I just disabled this section in my image, and in a rush, I could not find
out what is missing. What has been the purpose of this snippet?
I also see this might be a debatable behavior: On the one hand, the user
might be irritated when he is returning to a textmorph after a long time,
trying to extend the selection with <shift>Arrow right but the selection is
shrinked indead. On the other hand, I have activated the
#mouseOverForKeyboardFocus setting (which is basically genius) and find it
annoying that the selection behavior changes after repositioning your mouse.
Has this ever been debated before?

I would welcome your opinions!

Best,
Christoph

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Christoph Thiede

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

In reply to this post by marcel.taeumel

Hi,

currently, the editor is not replaced after #setText:, is it? Couldn't it be
troublesome to reset the editor in #setText: if styling is executed deferred
and the user made a new RTL selection?

@Chris: I have nearly the same preferences, but also activated the third
option (where I couldn't find any difference when toggling it). But I don't
see how this solves the problem?

Best,
Christoph

--
Sent from: http://forum.world.st/Squeak-Dev-f45488.html

Carpe Squeak!

Chris Muller-3

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede <[hidden email]> wrote:

Hi,

currently, the editor is not replaced after #setText:, is it? Couldn't it be
troublesome to reset the editor in #setText: if styling is executed deferred
and the user made a new RTL selection?

@Chris: I have nearly the same preferences, but also activated the third
option (where I couldn't find any difference when toggling it).

It affects whether clicking on one of the window buttons (close, menu, minimize, maximize) of a background window will activate the button, or simply bring the window to the front first, at which point the button will respond -- like an exception to the "Contents always active". Marcel did a brilliant job on it.

But I don't
see how this solves the problem?

You're right, it doesn't solve it, I simply tried to reproduce your issue in trunk image with my settings, but couldn't. In a stock image (default settings), I could. I didn't research why.

Best,

Chris

marcel.taeumel

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

Hi all.

That issue should be fixed in Trunk by now. If I recall correctly, Eliot found other examples in Transcript and Debugger windows that helped track down the bug.

Best,

Marcel

Am 06.08.2019 06:41:33 schrieb Chris Muller <[hidden email]>:

On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede <[hidden email]> wrote:
Hi,

currently, the editor is not replaced after #setText:, is it? Couldn't it be
troublesome to reset the editor in #setText: if styling is executed deferred
and the user made a new RTL selection?

@Chris: I have nearly the same preferences, but also activated the third
option (where I couldn't find any difference when toggling it).

It affects whether clicking on one of the window buttons (close, menu, minimize, maximize) of a background window will activate the button, or simply bring the window to the front first, at which point the button will respond -- like an exception to the "Contents always active". Marcel did a brilliant job on it.

But I don't
see how this solves the problem?

You're right, it doesn't solve it, I simply tried to reproduce your issue in trunk image with my settings, but couldn't. In a stock image (default settings), I could. I didn't research why.

Best,
Chris

Christoph Thiede

Re: Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

> 06.08.2019 06:41:33

Great that someone keeps track of all our bugs! The mailing list would descend into chaos without your support ... :-)

Von: Squeak-dev <[hidden email]> im Auftrag von Taeumel, Marcel
Gesendet: Montag, 6. Januar 2020 16:44:57
An: Chris Muller; JOHN SARKELA via Squeak-dev
Betreff: Re: [squeak-dev] Possible bug in PluggableTextMorph: Selection is reversed when rehovering text

Hi all.

That issue should be fixed in Trunk by now. If I recall correctly, Eliot found other examples in Transcript and Debugger windows that helped track down the bug.

Best,

Marcel

Am 06.08.2019 06:41:33 schrieb Chris Muller <[hidden email]>:

On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede <[hidden email]> wrote:

Hi,

currently, the editor is not replaced after #setText:, is it? Couldn't it be
troublesome to reset the editor in #setText: if styling is executed deferred
and the user made a new RTL selection?

@Chris: I have nearly the same preferences, but also activated the third
option (where I couldn't find any difference when toggling it).

It affects whether clicking on one of the window buttons (close, menu, minimize, maximize) of a background window will activate the button, or simply bring the window to the front first, at which point the button will respond -- like an exception to the "Contents always active". Marcel did a brilliant job on it.

But I don't
see how this solves the problem?

You're right, it doesn't solve it, I simply tried to reproduce your issue in trunk image with my settings, but couldn't. In a stock image (default settings), I could. I didn't research why.

Best,

Chris

Carpe Squeak!