Hi,

Thanks for reply.

I was thinking of using a block, but I was unsure how to use it :-)

I will see what I can come up with.

The functionality must work according to what color picker i selected in the preference for color picker also ;-)

Happy new year

Best,

Karl

On Fri, Jan 1, 2016 at 2:43 PM, marcel.taeumel <Marcel.Taeumel@hpi.de> wrote:

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.