A Proposal for Project Layers

Dean_Swan at Mitel.COM Dean_Swan at Mitel.COM
Tue Nov 16 23:53:05 UTC 1999



From:  Dean Swan at MITEL on 11/16/99 06:53 PM

Well, my $.02 is more of a question than anything, and may only be remotely
related to the Project Layers/namespace issue, but here it is:

As I've mentioned in the past, I'm working on some UI things to make life a
little more pleasant with Squeak on the Casio E-105.  I've implemented a class
#SoftwareCursor, as a subclass of #Cursor, which adds the ability to display
itself, and remember what was at the cursor location before displaying the
cursor.  The problem with this is that much of the commonly used protocol for
cursors is defined as class methods, for example:

     Sensor currentCursor: Cursor normal.

I want/need to make the global #CurrentCursor be an instance of my new
#SoftwareCursor, but there are 169 references (in a 2.5 image) to Cursor, like
my example above, and messages like 'Cursor normal' return instances of #Cursor,
so even if I change #CurrentCursor to an instance of #SoftwareCursor, it won't
be long before somebody comes a long and turns it back into a #Cursor.

I've been trying to come up with a way to allow an instance of #SoftwareCursor
to be assigned to #CurrentCursor, but still maintain the ability to use the host
OS/hardware cursor when/if it exists, and minimize any needed changes in the
rest of the system.  I was thinking about using a system preference to enable
the software displayed cursor.

I have all but concluded that the best way to solve my problem is to just add
'saveForm, savePoint, hideLevel' to #Cursor, as instance variables (these are
the additional instance variables for #SoftwareCursor), and modify #copyBits in
#BitBlt to deal with the case when [destForm == Display] to "hide" the cursor
before the Blit, and and "show" it after.  This is the only way I can think of
to avoid modifying all of the #Cursor class methods to check if we should be
using a #SoftwareCursor, or all of the references to #Cursor in the image (*NOT*
something I would want to do).

It's situations like this that almost make me want to side with the functional
purists (i.e. no side effects allowed).

I only mention this in the context of Project Layers because it would be nice to
be able to use a Project/Namespace type of mechanism to resolve my problem.
HMM's Collage system sounds appealing in this respect because I need to make
changes to two (Cursor, BitBlt) base classes that live very close to "the
metal".

A couple of other random thoughts on this topic: Is there any danger of
ProjectLayers/Namespaces opening the loop that is closed by the
#Behavior/#Metaclass/#Class hierarchy?  And.... Is the mechanism implemented in
the #Behavior/#Metaclass/#Class hierarchy of any use in implementing
ProjectLayers as Dan has described them so far?

I only ask because it seems that something like this goes on with every message
send, when the VM needs to figure out which methodDictionary to use (i.e. is it
a class method, or an instance method?).  Forgive me if I'm way off base here.

Maybe my situation is somewhat unique since I'm working on something that is so
intrinsic to the whole environment.  I don't want to penalize users who have
hardware cursors by forcing the use of the software cursor all the time, but I
do want to add the capability for platforms that need it, be able to run the
same image on both kinds of targets, and implement the new functionality
entirely in Smalltalk.  I think ProjectLayers in some form or other may be a
good way to solve my problem.


                                   -Dean Swan
                                   dean_swan at mitel.com





More information about the Squeak-dev mailing list