[Pharo-project] SystemWindow updatablePanes ivar
Hello, I completely lost in the logic of this thing. why a SystemWindow cares about something called panes? What if my window don't having/needs any of them? Why Object cares about #updateListsAndCodeIn: aWindow ??? If model is updated, then it should just send #changed, or self changed: #myPaneFoo and if SystemWindow's pane is dependent, it will be updated. What the point in using #verifyContents... This thing needs to be cleaned up. -- Best regards, Igor Stasenko AKA sig.
On Jan 17, 2010, at 4:33 AM, Igor Stasenko wrote:
Hello,
I completely lost in the logic of this thing.
why a SystemWindow cares about something called panes? What if my window don't having/needs any of them? Why Object cares about #updateListsAndCodeIn: aWindow ???
If model is updated, then it should just send #changed, or self changed: #myPaneFoo and if SystemWindow's pane is dependent, it will be updated.
May be this is related to the fact that the style gets propagated to its subcomponent. I know I was bitten by that some years ago.
What the point in using #verifyContents...
This thing needs to be cleaned up.
yes ;)
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/1/17 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 17, 2010, at 4:33 AM, Igor Stasenko wrote:
Hello,
I completely lost in the logic of this thing.
why a SystemWindow cares about something called panes? What if my window don't having/needs any of them? Why Object cares about #updateListsAndCodeIn: aWindow ???
If model is updated, then it should just send #changed, or self changed: #myPaneFoo and if SystemWindow's pane is dependent, it will be updated.
May be this is related to the fact that the style gets propagated to its subcomponent. I know I was bitten by that some years ago.
What the point in using #verifyContents...
This thing needs to be cleaned up.
yes ;)
I perusing the code in PluggableXXX classes, and i feel sick of it. All PluggableXXX classes has many repeatable patterns, like declaring getXXXSelector, which then serves for fetching the properties from model , like list, selected item, lable etc.. And this is also related to #update: method, which these morphs handling usually like: update: property property == getXXXSelector ifTrue: [ propertyXValue := model perform: getXXXSelector ] property == getYYYSelector ifTrue: [ propertyYValue := model perform: getYYYSelector ] So, each morph, which depends from model, has to pull the value from model manually. But, we could do the same, by pushing the property to dependents. MyModel>>setMyProperty: value ^ self notifyChange: #myProperty from: myProperty to: (myProperty := value ) MyModel>>notifyChange: propertyName from: oldValue to: newValue self dependents do: [:each | ( each perform: ('update', propertyName) asSymbol ) value: oldValue value: newValue MyMorph>>updateMyProperty ^ [:oldValue :newValue | self doSomethingWith: oldValue and: newValue ] in the above, a model just pushing new values, and morph handling updates directly, without need to keep getXXXSelector ivars to know, how to retrieve some property from model, or determine the correspondence between property name and way how to handle it.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I'm bad with ui but I was laways wondering why we would like to have non pluggable widgets. Stef
Hello,
I completely lost in the logic of this thing.
why a SystemWindow cares about something called panes? What if my window don't having/needs any of them? Why Object cares about #updateListsAndCodeIn: aWindow ???
If model is updated, then it should just send #changed, or self changed: #myPaneFoo and if SystemWindow's pane is dependent, it will be updated.
May be this is related to the fact that the style gets propagated to its subcomponent. I know I was bitten by that some years ago.
What the point in using #verifyContents...
This thing needs to be cleaned up.
yes ;)
I perusing the code in PluggableXXX classes, and i feel sick of it. All PluggableXXX classes has many repeatable patterns, like declaring getXXXSelector, which then serves for fetching the properties from model , like list, selected item, lable etc.. And this is also related to #update: method, which these morphs handling usually like:
update: property property == getXXXSelector ifTrue: [ propertyXValue := model perform: getXXXSelector ] property == getYYYSelector ifTrue: [ propertyYValue := model perform: getYYYSelector ]
So, each morph, which depends from model, has to pull the value from model manually. But, we could do the same, by pushing the property to dependents.
MyModel>>setMyProperty: value ^ self notifyChange: #myProperty from: myProperty to: (myProperty := value )
MyModel>>notifyChange: propertyName from: oldValue to: newValue self dependents do: [:each | ( each perform: ('update', propertyName) asSymbol ) value: oldValue value: newValue
MyMorph>>updateMyProperty ^ [:oldValue :newValue | self doSomethingWith: oldValue and: newValue ]
in the above, a model just pushing new values, and morph handling updates directly, without need to keep getXXXSelector ivars to know, how to retrieve some property from model, or determine the correspondence between property name and way how to handle it.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (2)
-
Igor Stasenko -
Stéphane Ducasse