Squeak 2.4 on Casio E105 observations
usinet.skoren at ibm.net
Thu Aug 5 23:36:52 UTC 1999
Oops sorry, thought you had a E100, Dean.
Yes I got the email, but I didnt' go the button route since I don't like the
Menu app that comes with the Casio.
1) Hm I'm not familiar with Alan Kay's recognizer. Any pointers would be
2/3) The Action button/wheel on the Casio E105 works nicely for scrolling
through text and flap-out menus. This is actually quite nice and you only
have to tap to either open the flap or get the cursor in the text pane.
Using the cursor pad would be a good cursor implementation, but I really
prefer using the pen. I can tap faster than I can move the pad around ;-)
Once I tap into something like a pane or a menu I think the cursor pad would
work well, but don't dismiss the pen entirely.
You could map the Menu/Todo/Contact buttons on the E105 to the colors if you
want. As to the cursor, the Casio doesnt' need it. The only cursor it
would need is the I-beam/carat in text panes.
4) Hm this sounds fairly funky. You could only have as many tabs as fit
across the width of the screen. If you're going to have one tab per
window(?) that limits the number of windows you can have open. Which may
not be a problem. But I think a more intuitive (and standard) way of doing
this would be to have a menubar across the top (or bottom) of the window
with a Window option that lets you switch across active windows. Or even
simpler a single fixed button in a corner that switches to the next
available open window. Or you could map one of the E105's buttons to
switch. Speaking of menus, a more standard menubar would save on real
estate as opposed to using the pop up menu in the "keep open mode" the way I
5) Hm not sure unless the physical screen is larger than the
displayed/viewable screen. That is the physical screen extends beyond the
edges of the cover and is unusable.
6) This would be ok if you remap the cursor pad properly. Keep north on the
cursor aligned with north on the screen. Also, if you do this you would
definitely have to come up with a seperate Squeaky-keyboard. You wouldnt'
be able to use the Casio keyboard or Jot. I'm not sure about the internals
of how Squeak deals with fonts, but if you come up with your own set of soft
fonts rotated appropriately, flipping the browsers and such *should* be
doable by remapping x and y coords.
Although the full blown Squeak loads into the E105, it's still a bit of
overkill. There's no reason to carry around the embedded c code and
smalltalk->c translator functionality. There's probably a lot of other
functionality we could shrink out. Also, is there any reason why we have to
keep the full *.sources and *.changes file around? Could we strip out some
of the content or maybe getting the VM to read a compressed version of both
would be more useful. You'd take a startup speed hit on decompressing the
two files into memory, but you'd gain back a lot of valuable storage space.
From: Dean_Swan at Mitel.COM [mailto:Dean_Swan at Mitel.COM]
Sent: Thursday, August 05, 1999 6:21 PM
To: Serg at VisualNewt.com
Subject: RE: Squeak 2.4 on Casio E105 observations
From: Dean Swan at MITEL on 08/05/99 06:21 PM
First, I have an E105, not an E100.
Second, Serg, I sent you a mail with
details on how I got Squeak going on the E105. I created a directory
Files\Squeak, and put Squeak.exe, Squeak3d.dll, SqueakV2.Sources,
Squeak.changes, Squeak.image all in that directory, then using the Casio
utility, I created a button that launched "\Program Files\Squeak\Squeak.exe
\Program Files\Squeak\Squeak.image". This works fine, with nothing but a
Squeak build and what came in the box with the Casio E-105.
And yes, there are a number of "issues" with WinCE on the Casio. The
screen keyboard is a little flaky, and I too have thought of writing one in
Squeak. Other observations:
1) Alan Kay's character recognizer works, and <pretty darn fast> at
so the slow menu
popups are a bit baffling. One thought I had is that the WinCE
Andreas's Win32 VM doesn't
support the "VM Preferences" as does the 95/NT version, and one of
preferences referenced in
the source code is "Delayed Screen Updates" which defaults to "on".
Could this have anything to do
2) Since WinCE doesn't display the cursor, and uses screen taps in
button clicks, the standard
user interface is very unpleasant and difficult to use.
3) There is a FREE third party utility from Conduits Technology that
you to re-map the hardware
buttons to generate keypresses that can be processed in Squeak. I'm
thinking about hacking
something in to use them as the red, yellow, and blue mouse buttons,
displaying the cursor, and
ignoring screen taps to at least achieve a reasonable level of
usability. Also, using the cursor pad
to control the mouse cursor is probably a good idea (anybody
Squeak with the equivalent of a 1 button mouse and no keyboard (at
no ALT or Cmd key) is
a pretty challenging environment to work in - not impossible, just
4) I've done quite a bit of looking into ways of making good use of
screens. I've come to the
conclusion that a full screen multi-page tabbed window is probably
best thing I can implement
in the near future. To that end I'm considering a browser clone
uses one tabbed page for each
pane, and an extra tabbed page for the desktop/Display. This would
one click access to any
pane and a fairly large display area for each pane.
5) Display extent. returns 232 at 309 on the E-105, rather than the
240 at 320. Any ideas?
6) I've been rummaging through the Squeak source code trying to figure
a good, simple way to
implement a "landscape" mode (as opposed to the Casio's default
"portrait' screen orientation).
This would help out a lot, as the standard SystemBrowser really
the width more than the height.
Any suggestions on this would be welcome.
7) Item 6 above has got me thinking that MVC and Morphic both suffer
what seems to me like an
awful lot of message sends for every user event. I've been toying
the idea of a dispatch array
that contains one entry for each pixel on the screen, and using
to create a ColorForm (probably
of depth 16 bits) to provide the index into the dispatch array, so
clicking at a particular screen location
would just directly call the appropriate method for whatever is
currently displayed at that location.
This would be somewhat analogous to HTML image maps, but with a
(invisible) layer so
the visible image would not have to bear any resemblance to the
dispatch map. Any thoughts
or advice on implementing this? It seems that it would be faster
simpler (albeit a bit more
glutinous in terms of memory consumption) than the current
Just a few final thoughts: Ever since I read about Alan Kay's "Dynabook"
concept almost twenty years ago, I have wanted such a device. Squeak on the
E-105 is the closest I've come yet, although until I can work out the UI
my Psion S5 is still more useable, and the machine I depend on for *most* of
Also, has anyone noticed how Dan Ingall's article in the August 1981 byte on
Smalltalk VM implementation talked about "small" VM implementations (i.e.
of K bytes rather than the 100's of K bytes of most Squeak VM's)? I can't
beleive that C should produce a VM implemenation that's an order of
larger than an assembly implementation. Where's the bloat coming from?
More information about the Squeak-dev