A new version of Morphic was added to project The Inbox:
==================== Summary ====================
Time: 24 January 2021, 5:22:59.352273 pm
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') -----
"select everything, invoked by cmd-a. 1/17/96 sw"
self selectFrom: 1 to: self string size.
+ morph skipOnceScrollSelectionIntoView.
Item was changed:
----- Method: PluggableTextMorph>>scrollSelectionIntoView: (in category 'editor access') -----
"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 valueOfProperty: #skipScrollSelectionIntoView ifAbsent: [false]) ifTrue: [
+ self removeProperty: #skipScrollSelectionIntoView.
+ ^ true].
textMorph editor hasSelection
ifFalse: [self scrollToShow: (textMorph editor startBlock withWidth: 1)]
self scrollToShow: (textMorph editor startBlock topLeft corner: textMorph editor stopBlock bottomLeft).
self scrollToShow: (textMorph editor pointBlock withWidth: 1). "Ensure text cursor visibility."].
Item was added:
+ ----- Method: TextMorph>>skipOnceScrollSelectionIntoView (in category 'as yet unclassified') -----
+ self owner owner setProperty: #skipScrollSelectionIntoView toValue: true.!
-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.
P.S.: All these "skip once if"-blah rules with little to no benefits can quickly blow up the code base. ;-)
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?
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
|Free forum by Nabble||Edit this page|