[Pharo-project] about Shout default to shout any text?
Alain either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. Because we have a lot of place (like workspace, some inspector panes So what do you think? Stef
All editors should be shout-able, but they should only be shouted if their model implements #shoutAboutToStyle: or whatever specific callback the system configured shouter is using. If CodeEditor has support for shouting only, then OB is screwed again because there the extra behavior of CodeEditor (or SmalltalkEditor it is called, I think) is not wanted. Lukas On 4 September 2011 10:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Alain
either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. Because we have a lot of place (like workspace, some inspector panes So what do you think?
Stef
-- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 10:48 AM, Lukas Renggli wrote:
All editors should be shout-able, but they should only be shouted if their model implements #shoutAboutToStyle: or whatever specific callback the system configured shouter is using.
Yes I saw that. I'm still waiting for alain description to fully understand.
If CodeEditor has support for shouting only, This is not what I implied. More that some places like inspector may be hold a reference to text while they should to codeeditor and that in text shout default should be off.
then OB is screwed again because there the extra behavior of CodeEditor (or SmalltalkEditor it is called, I think) is not wanted.
OK Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........) Do you do that in OB? Stef
Lukas
On 4 September 2011 10:40, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Alain
either we should change some textEditor into CodeEditor (and the inverse) or we should make sure that by default texts are not shouted. Because we have a lot of place (like workspace, some inspector panes So what do you think?
Stef
-- Lukas Renggli www.lukas-renggli.ch
Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the package OB-Shout it adds a couple of #shoutAboutToStyle: methods to the models of the editors that require highlighting. The #shoutAboutToStyle: methods configure Shout as necessary with the class, extra bindings required, etc. Depending on the contents of the text pane (class def, method def, comment) Shout is configured differently, or even disabled. It is great that Alan is restoring this previous behavior again, because it made the system truly extensible (also with alternative highlighters like the PP based variation of Shout that Helvetia was using). Lukas -- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the package OB-Shout it adds a couple of #shoutAboutToStyle: methods to the models of the editors that require highlighting. The #shoutAboutToStyle: methods configure Shout as necessary with the class, extra bindings required, etc. Depending on the contents of the text pane (class def, method def, comment) Shout is configured differently, or even disabled.
It is great that Alan is restoring this previous behavior again, because it made the system truly extensible (also with alternative highlighters like the PP based variation of Shout that Helvetia was using).
sure we did not break it on purpose just lack of documentation. Now my point is that may be in addition the default behavior should be not to style. else we will have to put a aboutToStyle to any model that do not care about shoutatall. Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
On 4 September 2011 12:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the package OB-Shout it adds a couple of #shoutAboutToStyle: methods to the models of the editors that require highlighting. The #shoutAboutToStyle: methods configure Shout as necessary with the class, extra bindings required, etc. Depending on the contents of the text pane (class def, method def, comment) Shout is configured differently, or even disabled.
It is great that Alan is restoring this previous behavior again, because it made the system truly extensible (also with alternative highlighters like the PP based variation of Shout that Helvetia was using).
sure we did not break it on purpose just lack of documentation.
I did not say that. It is kind of surprising not to notice all the #shoutAboutToStyle: everywhere that are suddenly not used anymore :-/
Now my point is that may be in addition the default behavior should be not to style. else we will have to put a aboutToStyle to any model that do not care about shoutatall.
Not to style was the default behavior of Shout. Lukas
Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 1:00 PM, Lukas Renggli wrote:
On 4 September 2011 12:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the package OB-Shout it adds a couple of #shoutAboutToStyle: methods to the models of the editors that require highlighting. The #shoutAboutToStyle: methods configure Shout as necessary with the class, extra bindings required, etc. Depending on the contents of the text pane (class def, method def, comment) Shout is configured differently, or even disabled.
It is great that Alan is restoring this previous behavior again, because it made the system truly extensible (also with alternative highlighters like the PP based variation of Shout that Helvetia was using).
sure we did not break it on purpose just lack of documentation.
I did not say that.
I know :)
It is kind of surprising not to notice all the #shoutAboutToStyle: everywhere that are suddenly not used anymore :-/
learning is difficult when you have to learn too many things at once. You take the first actions that works and since it works your mental model does not push you to look for a better solution. Now with the help that alain is preparing then we will just read it, say ahhahah ok and behave correctly.
Now my point is that may be in addition the default behavior should be not to style. else we will have to put a aboutToStyle to any model that do not care about shoutatall.
Not to style was the default behavior of Shout.
ah ok. I do not understand then why the inspector shouts some unwanted text. I will have a look during one boring meetings one of these day.
Lukas
Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 1:53 PM, Stéphane Ducasse wrote:
On Sep 4, 2011, at 1:00 PM, Lukas Renggli wrote:
On 4 September 2011 12:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted. Not styled by default else we should really have a look at all the places where we should not shout and fix them. Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the package OB-Shout it adds a couple of #shoutAboutToStyle: methods to the models of the editors that require highlighting. The #shoutAboutToStyle: methods configure Shout as necessary with the class, extra bindings required, etc. Depending on the contents of the text pane (class def, method def, comment) Shout is configured differently, or even disabled.
It is great that Alan is restoring this previous behavior again, because it made the system truly extensible (also with alternative highlighters like the PP based variation of Shout that Helvetia was using).
sure we did not break it on purpose just lack of documentation.
I did not say that.
I know :)
It is kind of surprising not to notice all the #shoutAboutToStyle: everywhere that are suddenly not used anymore :-/
learning is difficult when you have to learn too many things at once. You take the first actions that works and since it works your mental model does not push you to look for a better solution. Now with the help that alain is preparing then we will just read it, say ahhahah ok and behave correctly.
Now my point is that may be in addition the default behavior should be not to style. else we will have to put a aboutToStyle to any model that do not care about shoutatall.
Not to style was the default behavior of Shout.
ah ok. I do not understand then why the inspector shouts some unwanted text. I will have a look during one boring meetings one of these day.
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation :) Ben
Lukas
Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
On 4 September 2011 14:05, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On Sep 4, 2011, at 1:53 PM, Stéphane Ducasse wrote:
On Sep 4, 2011, at 1:00 PM, Lukas Renggli wrote:
On 4 September 2011 12:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted.
Not styled by default else we should really have a look at all the places where we should not shout and fix them.
Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the
package OB-Shout it adds a couple of #shoutAboutToStyle: methods to
the models of the editors that require highlighting. The
#shoutAboutToStyle: methods configure Shout as necessary with the
class, extra bindings required, etc. Depending on the contents of the
text pane (class def, method def, comment) Shout is configured
differently, or even disabled.
It is great that Alan is restoring this previous behavior again,
because it made the system truly extensible (also with alternative
highlighters like the PP based variation of Shout that Helvetia was
using).
sure we did not break it on purpose just lack of documentation.
I did not say that.
I know :)
It is kind of surprising not to notice all the
#shoutAboutToStyle: everywhere that are suddenly not used anymore :-/
learning is difficult when you have to learn too many things at once. You take the first actions that works and since it works your mental model does not push you to look for a better solution. Now with the help that alain is preparing then we will just read it, say ahhahah ok and behave correctly.
Now my point is that may be in addition the default behavior should be not to style.
else we will have to put a aboutToStyle to any model that do not care about shoutatall.
Not to style was the default behavior of Shout.
ah ok. I do not understand then why the inspector shouts some unwanted text. I will have a look during one boring meetings one of these day.
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 2:08 PM, Lukas Renggli wrote:
On 4 September 2011 14:05, Benjamin <benjamin.vanryseghem.pharo@gmail.com> wrote:
On Sep 4, 2011, at 1:53 PM, Stéphane Ducasse wrote:
On Sep 4, 2011, at 1:00 PM, Lukas Renggli wrote:
On 4 September 2011 12:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Sep 4, 2011, at 11:11 AM, Lukas Renggli wrote:
Now may be the default should be inverted.
Not styled by default else we should really have a look at all the places where we should not shout and fix them.
Because it looks strange to have a red text in inspector left pane especially when shout tries to parse anOrderedCollection (........)
Do you do that in OB?
Yes, by default all panes in OB are not shouted. If you load the
package OB-Shout it adds a couple of #shoutAboutToStyle: methods to
the models of the editors that require highlighting. The
#shoutAboutToStyle: methods configure Shout as necessary with the
class, extra bindings required, etc. Depending on the contents of the
text pane (class def, method def, comment) Shout is configured
differently, or even disabled.
It is great that Alan is restoring this previous behavior again,
because it made the system truly extensible (also with alternative
highlighters like the PP based variation of Shout that Helvetia was
using).
sure we did not break it on purpose just lack of documentation.
I did not say that.
I know :)
It is kind of surprising not to notice all the
#shoutAboutToStyle: everywhere that are suddenly not used anymore :-/
learning is difficult when you have to learn too many things at once. You take the first actions that works and since it works your mental model does not push you to look for a better solution. Now with the help that alain is preparing then we will just read it, say ahhahah ok and behave correctly.
Now my point is that may be in addition the default behavior should be not to style.
else we will have to put a aboutToStyle to any model that do not care about shoutatall.
Not to style was the default behavior of Shout.
ah ok. I do not understand then why the inspector shouts some unwanted text. I will have a look during one boring meetings one of these day.
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled.
shoutEnabled return true if Shout classes are installed in the system. but I was talking about (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. which shout the text if the model do not know #shoutAboutToStyle: Ben
Lukas
-- Lukas Renggli www.lukas-renggli.ch
No, #shoutEnabled returning true makes it enabled.
shoutEnabled return true if Shout classes are installed in the system.
This is a bug then. #okToStyle should never be called when Shout is not installed. #shoutEnabled returns true, if the model might request highlighting. I suggested Alain to remove it, I don't think it was ever used.
(model respondsTo: #shoutAboutToStyle:) Â Â Â Â ifFalse: [^true].
which shout the text if the model do not know #shoutAboutToStyle:
No. The interaction is different: 1. TextMorph changes its contents. 2. TextMorph notifies its styler withe the morph and its model that there might be the need to style. 3. The styles does whatever it wants to do: - The null styler might ignore the request. - The ShoutStyler calls #shoutAboutToStyle: on the model to ask if and how to style (earlier versions also called #okToStyle before they called #shoutAboutToStyle:). - The ShoutStyler might also decide to auto format the text. I believe earlier versions of Shout could do that. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Sep 4, 2011, at 2:34 PM, Lukas Renggli wrote:
No, #shoutEnabled returning true makes it enabled.
shoutEnabled return true if Shout classes are installed in the system.
This is a bug then.
#okToStyle should never be called when Shout is not installed.
#shoutEnabled returns true, if the model might request highlighting. I suggested Alain to remove it, I don't think it was ever used.
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
which shout the text if the model do not know #shoutAboutToStyle:
No. The interaction is different:
1. TextMorph changes its contents. 2. TextMorph notifies its styler withe the morph and its model that there might be the need to style. 3. The styles does whatever it wants to do: - The null styler might ignore the request. - The ShoutStyler calls #shoutAboutToStyle: on the model to ask if and how to style (earlier versions also called #okToStyle before they called #shoutAboutToStyle:). - The ShoutStyler might also decide to auto format the text. I believe earlier versions of Shout could do that.
Ok I have no idea how it was before and we never touched Shout. So I will wait for alain because I'm more and more confused. Stef
Lukas
-- Lukas Renggli www.lukas-renggli.ch
which shout the text if the model do not know #shoutAboutToStyle:
No. The interaction is different:
1. TextMorph changes its contents. 2. TextMorph notifies its styler withe the morph and its model that there might be the need to style. 3. The styles does whatever it wants to do: Â - The null styler might ignore the request. Â - The ShoutStyler calls #shoutAboutToStyle: on the model to ask if and how to style (earlier versions also called #okToStyle before they called #shoutAboutToStyle:). Â - The ShoutStyler might also decide to auto format the text. I believe earlier versions of Shout could do that.
Ok I have no idea how it was before and we never touched Shout. So I will wait for alain because I'm more and more confused.
In other words, this is a double-dispatch where the type of the styler is revealed on the model. In case of Shout #shoutAboutToStyle: tells the model that Shout is ready to take further commands on how to style the input. This gives true extensibility and is also very efficient. Lukas -- Lukas Renggli www.lukas-renggli.ch
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled.
I do not get it okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self shoutEnabled ^ self class shoutEnabled shoutEnabled ^ (Smalltalk globals includesKey: #SHPreferences) and: [(Smalltalk globals at: #SHPreferences) enabled] so when shout is loaded self shoutEnabled = true self shoutEnabled ifFalse: [^ false]. So okToStyle will return true when the method shoutAboutToStyle: is not defined (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. and this is this default that I'm talking about. Because if we would return false then only places that specifically define shoutAboutToStyle would be styled. No? Stef
Hi all, just coming back ... yes if "not styled" is the default then #okToStyle should return false if #shoutAboutToStyle is not implemented by the model:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
should be:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^false].
Cheers Alain On 04/09/2011 14:25, Stéphane Ducasse wrote:
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled.
I do not get it
okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self
shoutEnabled ^ self class shoutEnabled
shoutEnabled ^ (Smalltalk globals includesKey: #SHPreferences) and: [(Smalltalk globals at: #SHPreferences) enabled]
so when shout is loaded self shoutEnabled = true
self shoutEnabled ifFalse: [^ false].
So okToStyle will return true when the method shoutAboutToStyle: is not defined
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
and this is this default that I'm talking about. Because if we would return false then only places that specifically define shoutAboutToStyle would be styled.
No?
Stef
On Sep 4, 2011, at 8:20 PM, Alain Plantec wrote:
Hi all, just coming back ...
yes if "not styled" is the default then #okToStyle should return false if #shoutAboutToStyle is not implemented by the model:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
should be:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^false].
Ok this is what I was thinking :) Tx alain.
Cheers Alain
On 04/09/2011 14:25, Stéphane Ducasse wrote:
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled.
I do not get it
okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self
shoutEnabled ^ self class shoutEnabled
shoutEnabled ^ (Smalltalk globals includesKey: #SHPreferences) and: [(Smalltalk globals at: #SHPreferences) enabled]
so when shout is loaded self shoutEnabled = true
self shoutEnabled ifFalse: [^ false].
So okToStyle will return true when the method shoutAboutToStyle: is not defined
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
and this is this default that I'm talking about. Because if we would return false then only places that specifically define shoutAboutToStyle would be styled.
No?
Stef
Alain it means that we should define shoutAboutToStyle: to certain places like inspector pane. Isn't? :) On Sep 4, 2011, at 8:20 PM, Alain Plantec wrote:
Hi all, just coming back ...
yes if "not styled" is the default then #okToStyle should return false if #shoutAboutToStyle is not implemented by the model:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
should be:
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^false].
Cheers Alain
On 04/09/2011 14:25, Stéphane Ducasse wrote:
The inspector is shouted because the "not to shout" was the default behavior of Shout, but now, okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self the bold part make the default behavior "to shout". So maybe this value should be changed. But let's wait for Alain explanation
No, #shoutEnabled returning true makes it enabled.
I do not get it
okToStyle self shoutEnabled ifFalse: [^ false]. (model respondsTo: #shoutAboutToStyle:) ifFalse: [^true]. ^model shoutAboutToStyle: self
shoutEnabled ^ self class shoutEnabled
shoutEnabled ^ (Smalltalk globals includesKey: #SHPreferences) and: [(Smalltalk globals at: #SHPreferences) enabled]
so when shout is loaded self shoutEnabled = true
self shoutEnabled ifFalse: [^ false].
So okToStyle will return true when the method shoutAboutToStyle: is not defined
(model respondsTo: #shoutAboutToStyle:) ifFalse: [^true].
and this is this default that I'm talking about. Because if we would return false then only places that specifically define shoutAboutToStyle would be styled.
No?
Stef
On 04/09/2011 22:26, Stéphane Ducasse wrote:
Alain
it means that we should define shoutAboutToStyle: to certain places like inspector pane. Isn't? :)
arrggh, I've tried and it exhibits a problem. see the end of the answer. yes, you can do it with a shoutAboutToStyle: something like: Inspector>>shoutAboutToStyle: aPluggableTextMorph ^ (aPluggableTextMorph getTextSelector = #contents) not because an inspector is made of two text views. The one for the contents should not be styled. Only the one for coding should. But this solution is not so good because the model is making an asumptions about the view. It considers that the argument responds to #getTextSelector and that #contents can be the value of the result. Another solution should be to directly set the text editors as not styled when the view is built. Regarding Inspector view, it is built by MorphicUIManager>>openInspector: asMorphOn: withLabel: Normally, sending #styled: to a PluggableTextMorph with true as argument set it as styled. I prefer this solution because of the separation of concern between the model and its view(s). But now that the default is "not styled", this solution is broken. Maybe we should re-introduce a 'styled' inst var and revise the #okToStyle implementation. I open an issue. Alain
On Sep 4, 2011, at 11:54 PM, Alain Plantec wrote:
On 04/09/2011 22:26, Stéphane Ducasse wrote:
Alain
it means that we should define shoutAboutToStyle: to certain places like inspector pane. Isn't? :)
arrggh, I've tried and it exhibits a problem. see the end of the answer.
yes, you can do it with a shoutAboutToStyle:
something like:
Inspector>>shoutAboutToStyle: aPluggableTextMorph ^ (aPluggableTextMorph getTextSelector = #contents) not
because an inspector is made of two text views. The one for the contents should not be styled. Only the one for coding should.
But this solution is not so good because the model is making an asumptions about the view. It considers that the argument responds to #getTextSelector and that #contents can be the value of the result.
Another solution should be to directly set the text editors as not styled when the view is built. Regarding Inspector view, it is built by MorphicUIManager>>openInspector: asMorphOn: withLabel: Normally, sending #styled: to a PluggableTextMorph with true as argument set it as styled.
right now the separation is bogus because to me a model should not refer to methods that cretae the UI. :) anyway. we will see that later. I do not like that Morphic UIMAnager define creation method of widgets
I prefer this solution because of the separation of concern between the model and its view(s). But now that the default is "not styled", this solution is broken. Maybe we should re-introduce a 'styled' inst var and revise the #okToStyle implementation. I open an issue.
:)
Alain
No, this is not strange. The view-creation code is completely separate from the model itself, even if it lives in the model class. The view creation code is never called from within the model and in fact could and should be packaged with the view. There are no references from the model to the view, multiple views can concurrently co-exist on the same model, and we can even support different view kinds at once (morphic, toolbuilder, seaside, ...) by creating different UI creation methods. Lukas On 5 September 2011 08:24, Alain Plantec <alain.plantec@yahoo.com> wrote:
right now the separation is bogus because to me a model should not refer to methods that cretae the UI. :) anyway. we will see that later.
yes, it is a bit strange to be allowed to directly manipulate a view element from them model. Alain
-- Lukas Renggli www.lukas-renggli.ch
Hi Lukas, I've no problem at all with the view creation. Indeed, the view creation is clean. Now, my point is about #shoutAboutToStyle: a PluggableTextMorph is passed as argument, so, from the model, one have a direct access to the view and to the view styler. So, the Model implementation can be broken if another view class is used instead of PluggableTextMorph. And what about the Inspector pane which has two text editors ? Only one has to be shouted. So how would you implement #shoutAboutToStyle: in this case ? Thanks Alain On 05/09/2011 09:06, Lukas Renggli wrote:
No, this is not strange. The view-creation code is completely separate from the model itself, even if it lives in the model class. The view creation code is never called from within the model and in fact could and should be packaged with the view. There are no references from the model to the view, multiple views can concurrently co-exist on the same model, and we can even support different view kinds at once (morphic, toolbuilder, seaside, ...) by creating different UI creation methods.
Lukas
On 5 September 2011 08:24, Alain Plantec<alain.plantec@yahoo.com> wrote:
right now the separation is bogus because to me a model should not refer to methods that cretae the UI. :) anyway. we will see that later.
yes, it is a bit strange to be allowed to directly manipulate a view element from them model. Alain
And what about the Inspector pane which has two text editors ?
Typically you have a separate model for each part of the UI. At least OB does it that way.
Only one has to be shouted. So how would you implement #shoutAboutToStyle: in this case ?
The same problem with the standard browser that was broken since the changes: there is a class definition (shouted) and a comment pane (not shouted). Lukas -- Lukas Renggli www.lukas-renggli.ch
participants (4)
-
Alain Plantec -
Benjamin -
Lukas Renggli -
Stéphane Ducasse