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.ht... Sent from the Squeak - Dev mailing list archive at Nabble.com.