TextMorphForEditView calls #textEdited: after every cmd action

Am 18.07.2019 19:13:44 schrieb Christoph Thiede <[hidden email]>:

Hi all,

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
TextMorphForEditView.)

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.

Best,
Christoph



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

Am 19.07.2019 16:57:17 schrieb Christoph Thiede <[hidden email]>:

Hi Marcel,

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.

keyStroke: evt

| view |

editView deleteBalloon.

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.

view scrollSelectionIntoView.

(self readOnly not and: hasUnacceptedEditsSinceKeystroke)

 ifTrue: [view textEdited: self contents]

hasUnacceptedEdits: aBoolean

"Set the hasUnacceptedEdits flag in my view."

aBoolean ifTrue: [hasUnacceptedEditsSinceKeystroke := true].

editView hasUnacceptedEdits: aBoolean

Best,

Christoph

---

Von: Squeak-dev <[hidden email]> im Auftrag von Marcel Taeumel <[hidden email]>
Gesendet: Freitag, 19. Juli 2019 08:08 Uhr
An: JOHN SARKELA via Squeak-dev <[hidden email]>
Betreff: Re: [squeak-dev] TextMorphForEditView calls #textEdited: after every cmd action

 

Hi Christoph,

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]. 

Best,

Marcel

Am 18.07.2019 19:13:44 schrieb Christoph Thiede <[hidden email]>:

Hi all,

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
TextMorphForEditView.)

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.

Best,
Christoph



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