TextMorphForEditView calls #textEdited: after every cmd action

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TextMorphForEditView calls #textEdited: after every cmd action

Christoph Thiede
Hi all,

I did not found out whether this is a known bug/limitation: When you press
<Cmd-a>, <Cmd-i> 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

Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: TextMorphForEditView calls #textEdited: after every cmd action

marcel.taeumel
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



Reply | Threaded
Open this post in threaded view
|

Re: TextMorphForEditView calls #textEdited: after every cmd action

Christoph Thiede
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



Carpe Squeak!
Reply | Threaded
Open this post in threaded view
|

Re: TextMorphForEditView calls #textEdited: after every cmd action

marcel.taeumel
Hi Christoph,

the idea with the stack was just a crazy thought experiment. :-D

I like your idea about combining keyStroke: *and* hasUnacceptedEdits: to only catch edits triggered by a key stroke, which usually indicates user input.

Best,
Marcel

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