A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1718.mcz
==================== Summary ====================
Name: Morphic-ct.1718 Author: ct Time: 24 January 2021, 5:22:59.352273 pm UUID: f630cc0f-15e2-5642-94f6-6277bb8d7bd4 Ancestors: Morphic-mt.1710
PluggableTextMorph: Fixes #selectAll to keep the current scroll position intact, as it is best practice in most modern editor implementations such as Chromium.
I'm very open to refactoring proposals, but otherwise I don't care if you merge this as-is. :-)
=============== Diff against Morphic-mt.1710 ===============
Item was changed: ----- Method: Editor>>selectAll: (in category 'typing/selecting keys') ----- selectAll: aKeyboardEvent "select everything, invoked by cmd-a. 1/17/96 sw"
self insertAndCloseTypeIn. self selectFrom: 1 to: self string size. + morph skipOnceScrollSelectionIntoView. ^ true!
Item was changed: ----- Method: PluggableTextMorph>>scrollSelectionIntoView: (in category 'editor access') ----- scrollSelectionIntoView: event "Scroll my text into view. Due to line composition mechanism, we must never use the right of a character block because the lines last character block right value always comes from a global container and is *not* line specific."
self rememberSelectionInterval. + (self valueOfProperty: #skipScrollSelectionIntoView ifAbsent: [false]) ifTrue: [ + self removeProperty: #skipScrollSelectionIntoView. + ^ true]. + textMorph editor hasSelection ifFalse: [self scrollToShow: (textMorph editor startBlock withWidth: 1)] ifTrue: [ self scrollToShow: (textMorph editor startBlock topLeft corner: textMorph editor stopBlock bottomLeft). self scrollToShow: (textMorph editor pointBlock withWidth: 1). "Ensure text cursor visibility."]. ^ true!
Item was added: + ----- Method: TextMorph>>skipOnceScrollSelectionIntoView (in category 'as yet unclassified') ----- + skipOnceScrollSelectionIntoView + + self owner owner setProperty: #skipScrollSelectionIntoView toValue: true.!
Hi :-)
-1 for adding #skipOnceScrollSelectionIntoView this way
What's exactly the benefit of putting this extra effort into the implementation? Under which circumstances is that extra scrolling a distraction? What do you want to do after "select all"? For all that we know, it might be accidental in other systems. :-)
Yet, I do like "visual stability" for such interactions. Maybe we can find a better "rule" to achieve that. Or maybe we can establish a paramter to "selectFrom:to:". There is already "invisible selection". Maybe we can add "stableSelection"? Or something like that.
Best, Marcel
P.S.: All these "skip once if"-blah rules with little to no benefits can quickly blow up the code base. ;-) Am 24.01.2021 17:23:15 schrieb commits@source.squeak.org commits@source.squeak.org: A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-ct.1718.mcz
==================== Summary ====================
Name: Morphic-ct.1718 Author: ct Time: 24 January 2021, 5:22:59.352273 pm UUID: f630cc0f-15e2-5642-94f6-6277bb8d7bd4 Ancestors: Morphic-mt.1710
PluggableTextMorph: Fixes #selectAll to keep the current scroll position intact, as it is best practice in most modern editor implementations such as Chromium.
I'm very open to refactoring proposals, but otherwise I don't care if you merge this as-is. :-)
=============== Diff against Morphic-mt.1710 ===============
Item was changed: ----- Method: Editor>>selectAll: (in category 'typing/selecting keys') ----- selectAll: aKeyboardEvent "select everything, invoked by cmd-a. 1/17/96 sw"
self insertAndCloseTypeIn. self selectFrom: 1 to: self string size. + morph skipOnceScrollSelectionIntoView. ^ true!
Item was changed: ----- Method: PluggableTextMorph>>scrollSelectionIntoView: (in category 'editor access') ----- scrollSelectionIntoView: event "Scroll my text into view. Due to line composition mechanism, we must never use the right of a character block because the lines last character block right value always comes from a global container and is *not* line specific."
self rememberSelectionInterval.
+ (self valueOfProperty: #skipScrollSelectionIntoView ifAbsent: [false]) ifTrue: [ + self removeProperty: #skipScrollSelectionIntoView. + ^ true]. + textMorph editor hasSelection ifFalse: [self scrollToShow: (textMorph editor startBlock withWidth: 1)] ifTrue: [ self scrollToShow: (textMorph editor startBlock topLeft corner: textMorph editor stopBlock bottomLeft). self scrollToShow: (textMorph editor pointBlock withWidth: 1). "Ensure text cursor visibility."].
^ true!
Item was added: + ----- Method: TextMorph>>skipOnceScrollSelectionIntoView (in category 'as yet unclassified') ----- + skipOnceScrollSelectionIntoView + + self owner owner setProperty: #skipScrollSelectionIntoView toValue: true.!
Hi Marcel,
sorry, somehow I must have lost track of this discussion. :-)
What's exactly the benefit of putting this extra effort into the implementation? Under which circumstances is that extra scrolling a distraction? What do you want to do after "select all"? For all that we know, it might be accidental in other systems. :-)
I use this quite often in non-Squeak systems to copy/backup a text somewhere else but I want to keep reading it from the latest position. If the scrollbar jumps to another position in this case, I need to scroll back to the original position. This can, especially in longer texts, be a very tedious task ... Just stumbled again upon this.
Another argument might be that neither jumping to the beginning nor jumping to the end of the text makes ultimate sense to me.
Yet, I do like "visual stability" for such interactions. Maybe we can find a better "rule" to achieve that. Or maybe we can establish a paramter to "selectFrom:to:". There is already "invisible selection". Maybe we can add "stableSelection"? Or something like that.
As mentioned earlier, I am very open to alternative implementations. :-) I'm not very deep in the editor's implementation, would you maybe like to propose a concrete pattern?
Best, Christoph
----- Carpe Squeak! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi,
just dumping two very similar issues here that might be worth to fix together ("stable selection"):
When selecting a text with the mouse and scrolling down while the mouse is still pressed, releasing the mouse button should not cause the scroll view to jump back to the beginning of the selection. When selecting a text with the keyboard (e.g., shift + arrow down) and scrolling down, pressing shift + arrow down again should not cause the scroll view to jump back to the beginning of the selection.
Hm ... the relevant senders are TextMorphForEditView>>#mouseUp: and TextMorphForEditView>>#keyStroke: ... PluggableTextMorph>>#scrollSelectionIntoView: always scrolls both ends of the selection into view ... Ideally, the editor could indicate which ends of the selection should be scrolled into view ... similar to #userHasEdited?
Best, Christoph
--- Sent from Squeak Inbox Talk
On 2021-05-28T12:54:07-05:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel,
sorry, somehow I must have lost track of this discussion. :-)
What's exactly the benefit of putting this extra effort into the implementation? Under which circumstances is that extra scrolling a distraction? What do you want to do after "select all"? For all that we know, it might be accidental in other systems. :-)
I use this quite often in non-Squeak systems to copy/backup a text somewhere else but I want to keep reading it from the latest position. If the scrollbar jumps to another position in this case, I need to scroll back to the original position. This can, especially in longer texts, be a very tedious task ... Just stumbled again upon this.
Another argument might be that neither jumping to the beginning nor jumping to the end of the text makes ultimate sense to me.
Yet, I do like "visual stability" for such interactions. Maybe we can find a better "rule" to achieve that. Or maybe we can establish a paramter to "selectFrom:to:". There is already "invisible selection". Maybe we can add "stableSelection"? Or something like that.
As mentioned earlier, I am very open to alternative implementations. :-) I'm not very deep in the editor's implementation, would you maybe like to propose a concrete pattern?
Best, Christoph
Carpe Squeak!
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Just in case you forgot: text can be selected in both directions, forward and backward. So, the beginning of a selection can be before or after the current viewport.
Thanks for looking into this!
Best, Marcel Am 12.10.2023 22:04:44 schrieb christoph.thiede@student.hpi.uni-potsdam.de christoph.thiede@student.hpi.uni-potsdam.de: Hi,
just dumping two very similar issues here that might be worth to fix together ("stable selection"):
When selecting a text with the mouse and scrolling down while the mouse is still pressed, releasing the mouse button should not cause the scroll view to jump back to the beginning of the selection. When selecting a text with the keyboard (e.g., shift + arrow down) and scrolling down, pressing shift + arrow down again should not cause the scroll view to jump back to the beginning of the selection.
Hm ... the relevant senders are TextMorphForEditView>>#mouseUp: and TextMorphForEditView>>#keyStroke: ... PluggableTextMorph>>#scrollSelectionIntoView: always scrolls both ends of the selection into view ... Ideally, the editor could indicate which ends of the selection should be scrolled into view ... similar to #userHasEdited?
Best, Christoph
--- Sent from Squeak Inbox Talk [https://github.com/hpi-swa-lab/squeak-inbox-talk]
On 2021-05-28T12:54:07-05:00, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Marcel,
sorry, somehow I must have lost track of this discussion. :-)
What's exactly the benefit of putting this extra effort into the implementation? Under which circumstances is that extra scrolling a distraction? What do you want to do after "select all"? For all that we know, it might be accidental in other systems. :-)
I use this quite often in non-Squeak systems to copy/backup a text somewhere else but I want to keep reading it from the latest position. If the scrollbar jumps to another position in this case, I need to scroll back to the original position. This can, especially in longer texts, be a very tedious task ... Just stumbled again upon this.
Another argument might be that neither jumping to the beginning nor jumping to the end of the text makes ultimate sense to me.
Yet, I do like "visual stability" for such interactions. Maybe we can find a better "rule" to achieve that. Or maybe we can establish a paramter to "selectFrom:to:". There is already "invisible selection". Maybe we can add "stableSelection"? Or something like that.
As mentioned earlier, I am very open to alternative implementations. :-) I'm not very deep in the editor's implementation, would you maybe like to propose a concrete pattern?
Best, Christoph
Carpe Squeak!
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org
-
Christoph Thiede -
christoph.thiede＠student.hpi.uni-potsdam.de
-
commits＠source.squeak.org -
Marcel Taeumel