[Cuis] ColorEditor updated

[Dan Norton]

Ran across this comment for ActiveModel and thought it was interesting, historically.

Part of update 5005u16-Events.cs:

"Change Set:		Events
Date:			11 February 2002
Author:			Rob Withers et al.

Published to 3.3a as 4756Events.cs

The NuBlue events code. Finally..."

The new event model, originally from VisualSmalltalk.
This includes #when:send:to: and friends, in Object (generic implementation) and 
ActiveModel (optimized implementation).
It renders the old change/update mechanism in Object and Model as obsolete, although still 
used.

 - Dan

On 2 Nov 2015 at 15:27, KenD wrote:

> On Mon, 02 Nov 2015 15:58:26 -0500
> "Dan Norton" <dnorton at mindspring.com> wrote:
> 
> >.. I was casting about for some name besides " #when:send:to:
> mechanism" for 
> > use in a brief essay on PluggableListMorph Principles of Operation
> when I came across 
> > Signals. I already wrote a paragraph on Dependency Mechanism.
> 
> I would talk about #when:send:to: as implementing the Observer
> Pattern.
> 
> > So, the simple principle here is to just use #when:send:to: and
> forget about or maybe 
> > deprecate #changed: and #update:? 
> 
> Yes.  Let us work to eliminate #changed: !
> 
> > However, I see a problem common to dependency and #when:send:to:
> which is the 
> > identification and explanation of the various symbols which are
> communicated as the 
> > parameters for send: or changed: . When you're trying to design a
> model or view similar to 
> > something already in existence, the tools are not much help with
> that.
> > 
> > I'm thinking maybe: document in comments? <rant>Nah. We don't do
> comments.</rant>
> 
> We should certainly add clarifying comments!
> 
> Your Comment Browser is a big help here.  Once people start using it
> more, comments will appear.
> 
> I suggest sending Juan a code update with an added "Open Comment
> Browser" Help menu item which autoloads the same way as
> TerseGuide.
> 
> 
> However, class comments are not usually where design patterns show
> up.  8^|
> 
> In the case of #when:send:to: I suggest a slightly larger discussion
> around building paned windows which update dependent panes.
> 
> What constitutes good style?  What code patterns help?
> 
> Think "Useful Code Patterns" to augment "Useful Expressions".
> 
> You can do your own example, but looking at the ColorEditor:
> 
> ColorEditor>>buildMorphicWindow
> 	"Create a useful ColorEditor window"
> 	
> 	self layoutMorph beRow; " A row of columns"
> 		 separation: 6;
> 		 addMorph: self buildColorPaneColumn;
> 		 addMorph: self buildSliderColumn;
> 		 addMorph: self buildRadioButtonColumn;
> 		 color: self backgroundColor.
> 		
> 	self model when: #colorChanged send: #refreshColor to: self.
> 	
> 	^ self
> 
> So trying for good style (hey, I need to improve here too!) one
> uses: 
> 
> [Class]>buildMorphicWindow
>     [Add (construct each pane).. to layout]
>     [Add self or panes as observers]
>   ^ self
> 
> Suggest
>   Smalltalk browseAllImplementorsOf: #buildMorphicWindow
> to see specific usage examples.
> 
> Of course, we will suffer some embarrassment as our real code is
> less than ideal. 8^(
> 
> But this is a great motivator to making our code better!  ;^)
> 
> 
> $0.02
> -KenD