Squeak 2.4 on Casio E105 observations

Serg Koren 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
appreciated.

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
tend to.

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.





-----Original Message-----
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

Serg/Andreas:

     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
\Program
Files\Squeak, and put Squeak.exe, Squeak3d.dll, SqueakV2.Sources,
Squeak.changes, Squeak.image all in that directory, then using the Casio
Menu
utility, I created a button that launched "\Program Files\Squeak\Squeak.exe
\Program Files\Squeak\Squeak.image".  This works fine, with nothing but a
normal
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
on
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
that,
so the slow menu
        popups are a bit baffling.  One thought I had is that the WinCE
build of
Andreas's Win32 VM doesn't
        support the  "VM Preferences" as does the 95/NT version, and one of
the
preferences referenced in
        the source code is "Delayed Screen Updates" which defaults to "on".
Could this have anything to do
        with it?

     2) Since WinCE doesn't display the cursor, and uses screen taps in
place of
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
allows
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
remember
Smalltalk/V DOS?).

        Squeak with the equivalent of a 1 button mouse and no keyboard (at
least
no ALT or Cmd key) is
        a pretty challenging environment to work in - not impossible, just
not
very pleasant.

     4) I've done quite a bit of looking into ways of making good use of
small
screens.  I've come to the
        conclusion that a full screen multi-page tabbed window is probably
the
best thing I can implement
        in the near future.  To that end I'm considering a browser clone
that
uses one tabbed page for each
        pane, and an extra tabbed page for the desktop/Display.  This would
give
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
expected
240 at 320.  Any ideas?

     6) I've been rummaging through the Squeak source code trying to figure
out
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
needs
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
from
what seems to me like an
        awful lot of message sends for every user event.  I've been toying
with
the idea of a dispatch array
        that contains one entry for each pixel on the screen, and using
BitBlt
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
separate
(invisible) layer so
        the visible image would not have to bear any resemblance to the
actual
dispatch map.  Any thoughts
        or advice on implementing this?  It seems that it would be faster
and
simpler (albeit a bit more
         glutinous in terms of memory consumption) than the current
interface
mechanisms.

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
issues,
my Psion S5 is still more useable, and the machine I depend on for *most* of
my
computing needs.

Also, has anyone noticed how Dan Ingall's article in the August 1981 byte on
the
Smalltalk VM implementation talked about "small" VM implementations (i.e.
10's
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
magnitude
larger than an assembly implementation.  Where's the bloat coming from?



                                   -Dean Swan





More information about the Squeak-dev mailing list