[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
|