[squeak-dev] TextMorphForEditView calls #textEdited: after every cmd action
christoph.thiede at outlook.de
Fri Jul 19 14:57:04 UTC 2019
thanks for your reply. Do you really think checking the stack would not violate any law of modularity, intuitive interfaces and low coupling?
But what is the problem with #hasUnacceptedEdits:? Why would you change this in PluggableTextMorph? I added an instvar hasUnacceptedEditsSinceKeystroke to the TextMorphForEditView, set it to true in #hasUnacceptedEdits: if aBoolean is true and set it to false in #keyStroke: immediately before calling super keyStroke. At first glance, I could not find any wrong behavior.
| view |
self editor model: editView model. "For evaluateSelection"
view := editView. "Copy into temp for case of a self-mutating doit"
(acceptOnCR and: [evt keyCharacter = Character cr])
ifTrue: [^ self editor accept].
hasUnacceptedEditsSinceKeystroke := false.
super keyStroke: evt.
(self readOnly not and: hasUnacceptedEditsSinceKeystroke)
ifTrue: [view textEdited: self contents]
"Set the hasUnacceptedEdits flag in my view."
aBoolean ifTrue: [hasUnacceptedEditsSinceKeystroke := true].
editView hasUnacceptedEdits: aBoolean
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Marcel Taeumel <marcel.taeumel at hpi.de>
Gesendet: Freitag, 19. Juli 2019 08:08 Uhr
An: JOHN SARKELA via Squeak-dev <squeak-dev at lists.squeakfoundation.org>
Betreff: Re: [squeak-dev] TextMorphForEditView calls #textEdited: after every cmd action
yes, the current implementation of #textEdited: is not perfect. It is difficult to seperate any change from user-made edits. We cannot even know whether those incoming user-input events are not generated by a script. :-)
If you want to get an overview of higher-level user edits, take a look at the following methods:
TextEditor (or SmalltalkEditor) class >> #initializeCmdKeyShortcuts
TextEditor (or SmalltalkEditor) class >> #initializeShiftCmdKeyShortcuts
Here is a crazy idea: In those editor methods (e.g., #paste), we could add a pragma (e.g. "<userEdit>") and then look for a method activation with that pragma on the stack in Editor >> #userHasEdited. :-D
I think we cannot just use PluggableTextMorph >> #hasUnacceptedEdits: to signal that #textEdited: because that would raise too many signals.
Or wouldn't it? Hmmm...
PluggableTextMorph >> #hasUnacceptedEdits: aBoolean
aBoolean ifTrue: [self textEdited: self text].
Am 18.07.2019 19:13:44 schrieb Christoph Thiede <christoph.thiede at outlook.de>:
I did not found out whether this is a known bug/limitation: When you press
, or any other shortcut that raises a read-only operation
into a TextMorphForEditView, #textEdited: is called. This is caused by the
"guess editing" in TextMorphForEditView>>#keyStroke:. I think this is an
unwanted behavior as some views might schedule some relevant behavior to any
real text edition. (For example, we are working at a sheet tool which
activates an edit mode when any edit is received. It is irritating to get
the edit mode activated whenever some text is selected via keyboard.)
I first tried to add another condition to the cheap check
but then, events like Control Paste did not raise a #keyStroke: call. Marcel
proposed the alternative to compare old and new contents. Personally, I
would not find this solution ideal, as it is possible that the view decides
to change its contents when the text is edited, and in this case it would
receive #textEdited: just after the keystroke. (Our sheet tool does so, by
the way. Do you think this is a non-abusing implementation? In our concrete
case, the alternative would be to override both PluggableTextMorphPlus and
Is there any existing hook to identify the latest modifying event/user
operation that could be used for a cheap check here? As someone who is not
familiar with Morphic-TextSupport, my best idea would be adding a state
variable (wasEdited) to the Editor, resetting it before calling super
keyStroke: and testing it afterwards. In case of TextEditors, it _might_ be
an option to consult its history (?), but that wouldn't be an universal
solution? I do not really find that would be beautiful solutions, and would
welcome any better proposals to learn from them.
Sent from: http://forum.world.st/Squeak-Dev-f45488.html
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev