How about Mouse? ;-)  Or Cheese?
S

On Monday, January 26, 1998 11:34 AM, Paul Fernhout 
[SMTP:kfsoft at netins.net] wrote:
> Tim Rowledge wrote:
> > Actually, I'd suggest it might be useful to indirect ALL calls to 
'outside' apis, so that the platform specific code can cleanly intercept 
any that might not be suitable; there aren't many so it wouldn't be too 
onerous. Let's see, malloc,
> >  fread, frite, fseek, fopen, fclose, math stuff.... that's about it. 
The easy way would be to have the SQ code refer to some munged name and to 
use macro definitions to make use of the 'normal' calls where acceptable.
> > Thus we could easily intercept all the file handling but leave macros 
for exp, floor, sin etc.
>
> I second this.
>
> When dealing with code for the Newton, which doesn't support files, this
> is a source of complexity. For the most part, it isn't that bad.  But
> there is one place in the VM when it starts up where the shell creates a
> file handle and passes it to the VM (for reading the image) which
> created the worst difficulty. That is one place that Squeak does not use
> its own file primitives and the workaround is ugly.
>
> It would help if there was a test program written in C that exercised
> the Squeak shell code. The test program woudl be much smaller than
> Squeak itself - like one hundred lines of code or so. That way a port
> could focus on getting a shell to work first.
>
> That test case could be as simple as:
> Draw a diagonal line, respond to a mouse down or key by drawing another
> line, play a sound, and maybe read a file. These could be individual
> tests or run together based on compiler flags.  One could progress in
> some arbitrary order - like first get the bitmap to work, then get
> keyboard, then the mouse, then files, then TCPIP, then sounds. There
> could be feedback provided at each stage by the test program.
>
> On a related issue, there is much value in having a machine independent
> GUI shell that collects keystrokes, tracks the mouse, interacts with
> file like streams, displays bitmaps, does TCP/IP, and plays and records
> sounds. With a little restructuring, the Squeak shell could turn into a
> beautiful machine independent framework on top of which *anything* could
> be placed. This might entail a slight performance hit depending on how
> nternal Squeak data structures like strings were passed to the shell.
>
> For example, if a group wanted to make a portable version of Python with
> TK widgets, they could just put it on top of the Squeak shell platform.
>
> This would potentially bring a lot more people into the machine
> independent Squeak shell API fold. Even though they wouldn't have much
> to say about Squeak, they might have an interest in porting the Squeak
> shell to new platforms for their own reasons, and then Squeak could
> follow. It might also multiply the number of people interested in
> sharing the work of maintaining and debugging existing Squeak shell
> ports.
>
> Maybe if the Squeak low level API had a name it would be treated more
> like a thing on its own. Anyone with a catchy name for the Squeak shell
> and related API?
> Conch?
> Squeak API? Squeak Happy?
> The Nest?
> Squeal?
> Low Squeak? Rumble?
>
> -Paul Fernhout
> Kurtz-Fernhout Software
> ===========================================================
> Developers of custom software and educational simulations
> Download our Garden Simulator for Windows & source from:
> http://www.gardenwithinsight.com
>