A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-ct.852.mcz
==================== Summary ====================
Name: Tools-ct.852 Author: ct Time: 30 June 2019, 1:53:09.36343 pm UUID: 24bcf5d5-2d7f-2c47-a3c3-f80b0bd5241e Ancestors: Tools-ct.851
Activate code styling for inspector panes in Debugger
=============== Diff against Tools-ct.851 ===============
Item was changed: ----- Method: Debugger>>buildFullWith: (in category 'toolbuilder') ----- buildFullWith: builder | windowSpec listSpec textSpec | windowSpec := builder pluggableWindowSpec new model: self; label: 'Debugger'; children: OrderedCollection new.
listSpec := builder pluggableListSpec new. listSpec model: self; list: #contextStackList; getIndex: #contextStackIndex; setIndex: #toggleContextStackIndex:; menu: #contextStackMenu:shifted:; icon: #messageIconAt:; helpItem: #messageHelpAt:; keyPress: #contextStackKey:from:; frame: (0@0 corner: 1@0.22). windowSpec children add: listSpec.
textSpec := self buildCodePaneWith: builder. textSpec frame: (0@0.22corner: 1@0.8). windowSpec children add: textSpec.
listSpec := builder pluggableListSpec new. listSpec model: self receiverInspector; list: #fieldList; getIndex: #selectionIndex; setIndex: #toggleIndex:; menu: #fieldListMenu:; keyPress: #inspectorKey:from:; frame: (0@0.8 corner: 0.2@1); help: 'Receiver''s\Instance\Variables' withCRs. windowSpec children add: listSpec.
+ textSpec := builder pluggableCodePaneSpec new. - textSpec := builder pluggableTextSpec new. textSpec model: self receiverInspector; getText: #contents; setText: #accept:; help: '<- Select receiver''s field' translated; selection: #contentsSelection; menu: #codePaneMenu:shifted:; frame: (0.2@0.8 corner: 0.5@1). windowSpec children add: textSpec.
listSpec := builder pluggableListSpec new. listSpec model: self contextVariablesInspector; list: #fieldList; getIndex: #selectionIndex; setIndex: #toggleIndex:; menu: #fieldListMenu:; keyPress: #inspectorKey:from:; frame: (0.5@0.8 corner: 0.7@1); help: 'Other\Context\Bindings' withCRs. windowSpec children add: listSpec.
+ textSpec := builder pluggableCodePaneSpec new. - textSpec := builder pluggableTextSpec new. textSpec model: self contextVariablesInspector; getText: #contents; setText: #accept:; help: '<- Select context''s field' translated; selection: #contentsSelection; menu: #codePaneMenu:shifted:; frame: (0.7@0.8 corner: 1@1). windowSpec children add: textSpec.
^builder build: windowSpec!
My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event?
As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet.
Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle?
I would be glad about any advices!
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph,
you could use the pattern for optional arguments in model callbacks such as in SimpleHierarchicalListMorph >> #keyStrokeAction: or EventHandler >> #send:to:withEvent:fromMorph:.
Or, since #aboutToStyle: is a hard-coded callback, you could just support another hard-coded version: #aboutToStyle:fromMorph:. Check it with #respondsTo: such as in TextEditor >> #evaluateSelectionAndDo:.
(In 2015, I removed the #respondsTo: check from PluggableTextMorphPlus >> #okToStyle:. Not sure why. Maybe performance reasons. I suppose that if a client configured #styler, that extra check felt unnecssary.)
Best, Marcel Am 30.06.2019 22:26:29 schrieb Christoph Thiede christoph.thiede@outlook.de: My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event?
As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet.
Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle?
I would be glad about any advices!
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Marcel,
thanks for the reply! I'll be happy to add a callback within the next days.
(Side question: Is there any reason why Symbol does not implement #valueWithPossibleArgs:? I think this could improve the code style of SimpleHierarchicalListMorph>>#keyStrokeAction: & Co.)
Best, Christoph
________________________________ Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Marcel Taeumel marcel.taeumel@hpi.de Gesendet: Montag, 1. Juli 2019 09:13 Uhr An: Robert via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Tools-ct.852.mcz
Hi Christoph,
you could use the pattern for optional arguments in model callbacks such as in SimpleHierarchicalListMorph >> #keyStrokeAction: or EventHandler >> #send:to:withEvent:fromMorph:.
Or, since #aboutToStyle: is a hard-coded callback, you could just support another hard-coded version: #aboutToStyle:fromMorph:. Check it with #respondsTo: such as in TextEditor >> #evaluateSelectionAndDo:.
(In 2015, I removed the #respondsTo: check from PluggableTextMorphPlus >> #okToStyle:. Not sure why. Maybe performance reasons. I suppose that if a client configured #styler, that extra check felt unnecssary.)
Best, Marcel
Am 30.06.2019 22:26:29 schrieb Christoph Thiede christoph.thiede@outlook.de:
My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event?
As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet.
Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle?
I would be glad about any advices!
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
Hi Christoph,
not sure how #valueWithPossibleArgs: would help in Symbol. Maybe you mean #valueWithEnoughArguments:?
Here are some related discussions: http://forum.world.st/valueWithPossibleArgument-vs-cull-tp5099526.html http://forum.world.st/Discussion-Creating-message-sends-via-anObject-selecto...
An instance of MessageSend could improve readability in SimpleHierarchicalListMorph >> #keyStrokeAction:
^ (MessageSend receiver: model selector: keyStrokeActionSelector) valueWithEnoughArguments: {event keyCharacter. self. event}
Best, Marcel Am 01.07.2019 10:22:50 schrieb Christoph Thiede christoph.thiede@outlook.de: Hi Marcel,
thanks for the reply! I'll be happy to add a callback within the next days.
(Side question: Is there any reason why Symbol does not implement #valueWithPossibleArgs:? I think this could improve the code style of SimpleHierarchicalListMorph>>#keyStrokeAction: & Co.)
Best, Christoph Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Marcel Taeumel marcel.taeumel@hpi.de Gesendet: Montag, 1. Juli 2019 09:13 Uhr An: Robert via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Tools-ct.852.mcz Hi Christoph,
you could use the pattern for optional arguments in model callbacks such as in SimpleHierarchicalListMorph >> #keyStrokeAction: or EventHandler >> #send:to:withEvent:fromMorph:.
Or, since #aboutToStyle: is a hard-coded callback, you could just support another hard-coded version: #aboutToStyle:fromMorph:. Check it with #respondsTo: such as in TextEditor >> #evaluateSelectionAndDo:.
(In 2015, I removed the #respondsTo: check from PluggableTextMorphPlus >> #okToStyle:. Not sure why. Maybe performance reasons. I suppose that if a client configured #styler, that extra check felt unnecssary.)
Best, Marcel Am 30.06.2019 22:26:29 schrieb Christoph Thiede christoph.thiede@outlook.de: My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event?
As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet.
Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle?
I would be glad about any advices!
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
On Mon, 1 Jul 2019, Christoph Thiede wrote:
Hi Marcel,
thanks for the reply! I'll be happy to add a callback within the next days.
(Side question: Is there any reason why Symbol does not implement #valueWithPossibleArgs:? I think this could improve the code style of SimpleHierarchicalListMorph>>#keyStrokeAction: & Co.)
We have Object >> #perform:withEnoughArguments: for that purpose.
Levente
Best, Christoph
Von: Squeak-dev squeak-dev-bounces@lists.squeakfoundation.org im Auftrag von Marcel Taeumel marcel.taeumel@hpi.de Gesendet: Montag, 1. Juli 2019 09:13 Uhr An: Robert via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Tools-ct.852.mcz Hi Christoph, you could use the pattern for optional arguments in model callbacks such as in SimpleHierarchicalListMorph >> #keyStrokeAction: or EventHandler >> #send:to:withEvent:fromMorph:.
Or, since #aboutToStyle: is a hard-coded callback, you could just support another hard-coded version: #aboutToStyle:fromMorph:. Check it with #respondsTo: such as in TextEditor >> #evaluateSelectionAndDo:.
(In 2015, I removed the #respondsTo: check from PluggableTextMorphPlus >> #okToStyle:. Not sure why. Maybe performance reasons. I suppose that if a client configured #styler, that extra check felt unnecssary.)
Best, Marcel
Am 30.06.2019 22:26:29 schrieb Christoph Thiede <christoph.thiede@outlook.de>: My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event? As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet. Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle? I would be glad about any advices! -- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
+1
That's more direct that via a MessageSend. :-)
Best, Marcel Am 01.07.2019 19:52:56 schrieb Levente Uzonyi leves@caesar.elte.hu: On Mon, 1 Jul 2019, Christoph Thiede wrote:
Hi Marcel,
thanks for the reply! I'll be happy to add a callback within the next days.
(Side question: Is there any reason why Symbol does not implement #valueWithPossibleArgs:? I think this could improve the code style of SimpleHierarchicalListMorph>>#keyStrokeAction: & Co.)
We have Object >> #perform:withEnoughArguments: for that purpose.
Levente
Best, Christoph
Von: Squeak-dev im Auftrag von Marcel Taeumel Gesendet: Montag, 1. Juli 2019 09:13 Uhr An: Robert via Squeak-dev Betreff: Re: [squeak-dev] The Inbox: Tools-ct.852.mcz Hi Christoph, you could use the pattern for optional arguments in model callbacks such as in SimpleHierarchicalListMorph >> #keyStrokeAction: or EventHandler >> #send:to:withEvent:fromMorph:.
Or, since #aboutToStyle: is a hard-coded callback, you could just support another hard-coded version: #aboutToStyle:fromMorph:. Check it with #respondsTo: such as in TextEditor >> #evaluateSelectionAndDo:.
(In 2015, I removed the #respondsTo: check from PluggableTextMorphPlus >> #okToStyle:. Not sure why. Maybe performance reasons. I suppose that if a client configured #styler, that extra check felt unnecssary.)
Best, Marcel
Am 30.06.2019 22:26:29 schrieb Christoph Thiede :
My desire was to activate styling in the Debugger's inspector panes for the case you type some expression into one of the panes. Unfortunately with this commit, each string representation of a selected instance/temporary var is styled as well. This is a general proposal about the Inspector: Do you think it would be a good idea to disable the styling when any variable is selected, and to activate it on any editText event?
As far as I found out, there is no option to identify the relevant PluggableTextMorphPlus from #aboutToStyle:, so my only idea would be to remember the morph in an instvar of the Inspector and set its styler each time* to nil respectively a styler object. But that looks kind of hacky to myself ... *The styler would have to be updated in #toggleIndex: as well as in a selector like #editText:, where the latter does not exist yet.
Do you think styling in Inspector would be worth these changes? Is there any better way to toggle styling (but looking at Workspace>>#toggleStyling, I do not think so)? Or would it even be worth thinking about introducing a custom selector to be called in PluggableTextMorphPlus>>#okToStyle?
I would be glad about any advices!
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
squeak-dev@lists.squeakfoundation.org
-
Christoph Thiede -
commits＠source.squeak.org -
Levente Uzonyi -
Marcel Taeumel