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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160101/e5957beb/attachment.htm