Squeak 2.4 on Casio E105 observations

Dean_Swan at Mitel.COM Dean_Swan at Mitel.COM
Mon Aug 9 16:40:57 UTC 1999

From:  Dean Swan at MITEL on 08/09/99 12:40 PM


     I got mine at CompUSA in Syracuse, NY.  They seemed to have quite a few of
them when I bought it on 12 July.  I'm also attaching a mail I exchanged with
Serg last week.  I meant to copy it to the list, but I guess I forgot.

                                   -Dean Swan


1) Alan Kay's Simple Character Recognizer

  Open a standard workspace, pop up the text editor menu, select
  "more...", then select "recognizer".

  It's fairly fussy, and seems to only like fully connected strokes
  (i.e. no mouse up-down sequence within a character), but the
  pen tracking is *very fast*, and it even recognizes many
  characters correctly.  This however, still needs work, as the
  comments in the source indicate.

2/3) User Interface issues:

  The "action" button sends the same keycode as "enter".  The wheel
  up/down functions send the same keycodes as either "pgUp/pgDn" or
  the up/down cursor keys.  I forget which.  The "exit" button (above
  the action button/wheel) sends "esc".

  The menu/todo/contact buttons are exactly what I was thinking of
  using for the mouse buttons.

  I agree that the pen is usually better and faster than the
  cursor pad would be, but have you ever tried to use your Casio in
  a moving vehicle (trains and plains don't count here).  The pen
  is nearly impossible to use while riding in a car/truck.

  Don't write off speech input as totally insane.  That may be
  something to consider.

  The text insertion carat is already there, but often in a color
  that isn't very different from the pane background.

  The reason I want to show the cursor at other times and not use
  screen taps as mouse clicks is: resizing panes and/or windows
  is difficult because you don't have a visual indicator of when
  your cursor point is in "resize" mode, as you do with the Mac or
  Windows implementations.

4) Browser for Small Screens - I won't engage in a religious debate,
   like the accessors/mutators thread.  I'll take my own advice on
   this point.  I'll build what I like and distribute it.  Then I'll
   gladly accept critiques, but I realize that user interfaces can
   be a very personal thing and "one-size-fits-all" will never do.

   (Which is better - EMACS or VI?  - see what I mean?  The correct
    answer is context dependent.)

5) I beleive that the physical screen is 240 at 320, and that there
  is either a bug in Squeak somewhere, a bug in WinCE reporting
  the screen size, OR this is the way it is supposed to work, and
  I just don't understand why.

6) Maintain cursor pad alignment when rotating the screen - agreed.

Memory footprint - many things in Squeak can be stripped to reduce
the footprint.  Personally, I like to keep *ALL* of the system
loaded because I like to read through the code to learn how things
are implemented.  There really is a lot there to learn from (about
300K lines of source).  I have thought about compressed sources,
but more for reasons of speed than any other.  Have you ever tried:

  Smalltalk browseMethodsWithSourceString: 'StartUpList'.

It takes a ...long... time, even on a 450 MHz Pentium or a 333 MHz


"Serg Koren" <usinet.skoren at ibm.net> on 08/05/99 07:36:52 PM

Please respond to Serg at VisualNewt.com

To:   Dean Swan/Ogd/Mitel at Mitel, Serg at VisualNewt.com
cc:   squeak at cs.uiuc.edu

Subject:  RE: Squeak 2.4 on Casio E105 observations

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


     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

                                   -Dean Swan

>Serg (and all) --
>Where did you get the CasioE105? -- I've had no luck with the dealers in LA
>that werelocated via the Casio website -- and the website sells the 100 but
>not the 105.

More information about the Squeak-dev mailing list