[squeak-dev] Re: Delayed preference color updating

marcel.taeumel Marcel.Taeumel at hpi.de
Fri Jan 1 13:43:11 UTC 2016


Hi Karl.

I like it the non-modal way. It feels more immediate/direct. The button
"close" does not suggest a "save operation." If we would make it modal, we
would have to add another button to have "Save" and "Cancel".

I don't like the way that the button/morph is used as a value holder for the
color because we rely on that the button does not modify the color
internally.

To solve this problem, I would rather directly invoke the color picker in
PBColorPreferenceView >> #changeColor:. For the new color picker, I would
add some processing block for the target as an alternative to the hard-coded
#color: message send. Like this:

(NewColorPickerMorph with: [:newColor |
   aButton color: newColor.
   self preference preferenceValue: newColor.
   aButton label: newColor asString.
   self adjustLabelColor]) openInWorld.

The color picker can evaluate the block with the new color as needed. The
block closures the button and the preference view.

Best,
Marcel



--
View this message in context: http://forum.world.st/Delayed-preference-color-updating-tp4868940p4868960.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.


More information about the Squeak-dev mailing list