[Norton, Chris]  (Some stuff was arbitrarily snipped to make my
point  ;-)

> > Marcel said: "Because Windows got it wrong..." about the cut/copy/paste
> key
> > sequences.
> 
> Hmmmmmm I dunno... it could be said that Apple got it wrong because Meta
> <argument against it>... I think it's not that much important exactly what
> button it is.
> 
> > You know Marcel, there isn't much we can do about what M$ did in the
> past.
> > However, all of the applications on my Windoze box do the cut/copy/paste
> > thing the same way; they all use Alt.
> 
> Hm? They all use Ctrl :).
> 
	[Norton, Chris]  Quite right Andres!  My mistake.  ;-)

> > In the interest of being "consistent" with all of the other apps on this
> 
> > platform (and apparently on UNIX too), I think that the Windoze version
> of 
> > Squeak should likewise use the same key sequences for this basic
> activity.
> 
> This will also change the current Ctrl-keys... Ctrl-v for instance gets
> you a
> signature of yourself plus the date. And although it goes against ehhh...
> the
> mass, I like that Squeak works with Alt instead.
> 
	[Norton, Chris]  Actually (if we are lucky) all of these special key
sequences will be soon be re-thought.  There are some folks in the community
that would love to refactor the Squeak menus and accelerator key sequences.
A lot of that stuff seems to have simply evolved over time.  It is my
assumption, having used the various indigenous tools for a few months now
(little joke), that no one has really taken a hard look at the menu contents
in some time.  Some small amount of refactoring could simplify the interface
quite a bit.

	Case in point:  I'd like to be able to type characters in a list box
and have the cursor go to the next entry that matches my keystroke.
Currently, this is impossible because we have special keystroke behavior
that does stuff like open up a Browser (b).  This special behavior should be
optional.

	Along these lines, I'd like to suggest that platform/OS specific
stuff (like the cut/copy/paste key maps) can and should be captured in a
generic KeyboardPolicy mechanism.  I have been working on a OsPolicy
hierarchy that could be used to model these platform specific things in a
generic and re-usable way.

	[PLEASE BE KIND -- this is just at the "hey wouldn't that be neat
phase!"; I haven't spent a lot of cycles on it yet]

	GenericOsPolicy (class var SystemPolicy, i-vars: keyboardPolicy,
pointingDevicePolicy, etc.)
	    WindowsOsPolicy
	    MacintoshOsPolicy
	    PDAOsPolicy

	KeyboardPolicy (this would be the "standard" Squeak keys)
	   Kb101KeyPolicy
	   KbMacintoshPolicy
	   KbWindows95Policy
	   KbCustomPolicy   (you could re-map your own preferences here)

	AbstractPointingDevice
	   Mouse
	      MouseTwoButton
	      MouseThreeButton
	   PenDevice
	   TabletDevice
	      
	In my dream, there would be a single instance of an OsPolicy class
kept in a class variable of GenericOsPolicy called SystemPolicy.
SystemPolicy would be set at image creation time to be the appropriate
OsPolicy for your operating system (it could be overridden, of course).  The
image builder, or the user, would configure the keyboardPolicy,
pointingDevicePolicy, etc., and all available Squeak tools would adjust
themselves appropriately (on the fly).  Thus a PDA image might define a nil
keyboard policy and a pointing device set to PenDevice.  The System Browser
and other tools would provide the user with special menus, etc., so that
Squeak would still be useful without a keyboard.

	Of course, my dream has a long way to go before it becomes a
reality.  However, I think that if this mechanism was fleshed out
appropriately, it could be used to wrap all machine dependent (or OS
specific) behavior.  People who come up with native widgets and API support
would access it in a generic way; the calls would be translated by the
Policy settings into something appropriate.  And if Squeak were to determine
that a particular setting was invalid (i.e. Mac settings on a Windows box),
it would return the "generic" Policy instead.  Thus you could write
applications that use native stuff across all platforms generically and if a
platform supported some portion of the "native" stuff, the application would
use it, otherwise it would use the generic mechanism (generic Squeak look &
feel).

	Just think about the neat kinds of stuff this could buy us:

*	Programmable mice & keyboards
*	Generic API calls that could be implemented for all platforms
(perhaps via VM calls?)
*	OS specific LookPolicies for widgets (swappable - maybe we'd want
lots of these!)
*	Generic File System stuff (just tie OsPolicy to the existing file
system code)

	I'm sure that you bright people could think of lots of other great
things that could be added too.  The important thing is that on the surface
would be the "generic" classes and behaviors that work across all platforms.

	Oh - one more thing...  Wouldn't it be super cool if we could define
alternate LookPolicy objects for existing widgets in Squeak?  For example:
a button could be represented as a plain old 2 color box, or as 3D box or as
a box with a graduated 3-color scheme, or as a box with a translucent image
that moving pictures could "drift" across (idea borrowed from Carl Gundel
:-)?  By tying a LookPolicy to each graphical element in Squeak, we could
provide for some very cool new widget "costumes"!

	That's enough for now - hope I haven't worn out my welcome!

	---==> Chris

	OK; I lied.  Here's another daydream.  Imagine that Dan Ingalls &
company has perfected the multi-image framework he described last month and
that somebody has gotten shareable images to work via the Internet & web
browsers.  OK.  So I'm collaborating on a project with somebody from Germany
or France and we both are sharing the same image via the Internet, but my
machine is a Windoze box and his/her machine is a Mac.  Now, somebody else
pulls up our image on a PDA.  AND it all still works.  AND all of the
widgets are represented natively.  AND all of this magic is transparent to
us all, because we configured our SystemPolicy once and it was saved in a
local flat file that we can file in each time we grab a new image!!!  OK.
I'm done now...   :-)   :-)   :-)