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
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 christoph.thiede@student.hpi.uni-potsdam.de: 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
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
On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede < christoph.thiede@student.hpi.uni-potsdam.de> 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
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 asqueaker@gmail.com: On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede <christoph.thiede@student.hpi.uni-potsdam.de [mailto:christoph.thiede@student.hpi.uni-potsdam.de]> 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
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 squeak-dev-bounces@lists.squeakfoundation.org 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 asqueaker@gmail.com:
On Mon, Aug 5, 2019 at 8:21 AM Christoph Thiede <christoph.thiede@student.hpi.uni-potsdam.demailto:christoph.thiede@student.hpi.uni-potsdam.de> 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
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 < christoph.thiede@student.hpi.uni-potsdam.de> 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
squeak-dev@lists.squeakfoundation.org
-
Chris Muller -
Christoph Thiede -
Marcel Taeumel -
Thiede, Christoph