Hi Lex!

[snipped object Policy hierarchy]

> Lex Spoon [SMTP:lex at cc.gatech.edu] said: 
> Sounds fine, but two notes.
> 
> First, it might be possible to make the policy objects instances instead
> of classes.  It all depends on what goes into a "policy".  You might have
> meant this, but I wanted to spell it out.
> 
> Which leads to the second note: what exactly goes into the policies?  So
> far, it's a mapping of keys -> editting commands, which could be a simple
> dictionary stored in some class or global variable.  A standard file
> format would be nice for these, so that people could share them around, or
> we could simply use Smalltalk code.  (Yet another menu item in the
> FileLists?  :( )
> 
> Anyway, I say, let's figure out what we really want to be able to
> customize, and then we can figure out what kind of abstraction will work
> best.  The general scheme of having global policy objects seems like a
> good one, but at this point, do we know what should actually go into them?
> 
[Norton, Chris]  I agree that the actual policy objects need to be instances
(how else would we accomplish the kind of swappability that I proposed? :-).
And it is most likely true that all "Policy" objects would inherit from an
abstract Policy class, so that they can share an interface.  However, I
expect that we will want some concrete classes to keep things straight.
KeyboardPolicy, AbstractPointingDevicePolicy, etc., might help to imply
usage.  I also expect that we will want to ask our currently defined
OsPolicy object questions (like...  what is my OS end of line character, or
what is my file name separator?).

Your second question is a good one.  As a community, we need to think about
what kinds of things would achieve added value from defining their "look &
feel" or "behavior" or "interface" by some swappable policy.  

I think the following policies might be a good place to start:
*	OS policy (Win / Mac / Unix / OS2 / PDA / Risc / etc.)
*	keyboard policy (programmable via a point & click
KeyboardPolicyEditorMorph (thanks Bolot Kerimbaev))
*	mouse / pointing device policy
*	generic API call calls (these would be optimized / customized for
each unique OsPolicy)
*	look policy for widgets / windows
*	sound policy for widgets / and for all of Squeak
*	image policy (this may be used to tell another image what classes
are available???  --  I'm not so sure about this one)

I'd love your input on this!  Anybody...  Wild suggestions are welcome.
This whole Policy concept can be as revolutionary (I know -- somebody else
already invented look policies in VisualWorks ;-) as pluggable primitives
and the portable kernel!  Wouldn't it be cool if you could tell your image
to display every widget "as if" it were running on some other OS?

Your Input Is Requested  (need space suit to travel ;-)

---==> Chris