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.

>
> 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
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

>>> 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
>>> [hidden email]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> [hidden email]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project