My one request would be to keep the Smalltalk portion of the code as 
portable (cross-platform capable as possible).  Try to follow the 
paradigm first set up by Squeak.  Put the hardware specific code into its 
own section under Interpreter Support Code.  Prefix the methods with 
something like sqWinAPI to distinguish it from potential other 'native' 
API sets such as sqMacAPI, etc.  That way us other Squeakers could reuse 
your work on other non-Windows platforms to include the native API sets.  
It's good to keep reminding oneself that "native Squeak" means Mac, 
Windows, Unix, WindowsCE, etc etc.  It just doesn't mean Windows/Unix ;-)



Squeak's mantra should be..."Keep it Portable...Keep it Portable...Keep 
it Portable...but if you can't, make sure you segregate all the hardware 
specific stuff into it's only central class or group."

And remember to add a method to strip the code out if someone doesn't 
want to use it ;-)



Thanks,
S



----- Andreas Raab said:

>> - Native windowing support
>> 
>> Although the Squeak windowing system is cool in itself and very adequate 
>> for most displaying needs, it would be fun if one could use it to 
>> write programs with a native look and feel. Is anyone up to the 
>> challenge? >:)
>
>I've been investigating this. There are however, a number of steps to go
>before you can use native windows such as:
>* Removing references to Display and allow for multiple DisplayMediums
>  to be the screen representation (in addition I would like to see an
>  abstraction like Canvas handling the display stuff)
>* Replacing PopupMenu and the notifiers
>* Change event handling to redirect events to the appropriate windows
>* ...
>
>Morphic might be the easier way to go since a couple of things are already
>there (i.e. Canvas and event handling) but there are other problems. In
>general, you can place any morph on any place in its world. This, in turn,
>would mean that if we are omitting the World (which is the Squeak window)
>we need to place any morph directly on the screen. I'm not really sure how
>to deal with that. Another approach could be allowing only SystemWindows
>to be native windows and allow the free placement of morphs only in
>certain panes (such as morph construction pane) which would be some sort
>of SystemWindow itself.
>
>If somebody wants to discuss the best way to go here, let me know.
>
>Andreas
>-- 
>Linear algebra is your friend - Trigonometry is your enemy.
>+===== Andreas Raab ============= (raab at isg.cs.uni-magdeburg.de) =====+
>I Department of Simulation and Graphics      Phone: +49 391 671 8065  I
>I University of Magdeburg, Germany           Fax:   +49 391 671 1164  I
>+=============< http://isgwww.cs.uni-magdeburg.de/~raab >=============+
>
>


-------------------------------------------------
VisualNewt Software: http://www.VisualNewt.com/

Maker of Newt'sPaper(tm) the Premier Newton(R)
MessagePad(tm) News Reader.
-------------------------------------------------