On Sat, 12 May 2001, Jim Benson wrote:

> Scott,
>
> >
> > For example, why are inlined error messages in the code done as a normal
> > text? You have to manually delete them before you can even save&recompile!
> >
>
> I'll assume that you mean you have gotten an error message while compiling a
> method. Two things here. First, notice that the error is highlighted
> (selected). In order to delete the error message, a one kestroke sequence is
> required. Second, in order to recompile and save the code, you must fix your
> error, which will require you to edit the text. If you are going to edit the
> text anyway, an extra keystroke does not seem to be a major penalty.

*nods* I know; I just dislike this interface; it should be intelligent
enough to delete the message automatically by itself when I attempt to
recompile.  :)


>
> The rest of the text discussion skeered me ;-) I don't want to have to worry
> about: "color, font, stipple, size, underline, overline, offset" text
> attributes. I just want to type in some methods and be done with it. I'm
> thinking a B-Tree to keep track of less than 50 or 60 tokens might be
> overkill, but that's just me :-)

For method editing, BTree is overkill... For scamper and elsewhere... Yes!


Even for methods, assign tags to selector names, local variables, global
variables, etc. Let the user choose the display semantics for these tags..
Instant highly customizable semantic coloration. If this functionality,
even it it didn't scale to large amounts of text, I'd go 'yeah' and be
happy, but it doesn't seem to exist at all.

Do it once, make it reasonably scalable (O(n log n) instead of O(n^2)) and
use it for the next decade... TK's textbox was written 9 years ago and is
basically unchanged.


> >
> > TK also has another nice architecture, the event-handling architecture.
> > Events may be attached to either widgets or as event tags:
> >
>
> Squeak does basically the same thing but uses methods for message passing
> instead of blocks once the hardware event is dispatched. So, the World
> basically figures out which morph to give the event to, and the morph then
> figures out what to do with the event. Generally, something with underlying
> data like a SystemWindow has a model to facilitate interactions among
> related widgets. As an example, a widget could receive an event, and then
> tell its model to execute an associated command shortcut by sending a
> message to the model. The model in turn broadcasts the necessary information
> to other interested parties, a moderator if you will. In Smalltalk, objects
> talk to other objects using message passing, and is optimized towards that
> metaphor. Hardware event dispatching is used as a crutch to talk to that
> nasty, ugly hardware stuff.
>

I'm not quite following what you mean by hardware event handling, or the
rest of the event handling in Morphic.. It *appeared* that events were
hardcoded as methods like 'step' that are invoked directly on an object,
and have to be overridden in subclasses?

Ahh... MorphicExtension, which seems to be basically a technique to let
groups of morphs share a set of event handlers.. A lot like eventtags in
TCL.


Anyways, this is the type of thing thats really hard to grok only through
browsing code, unless you've got an 'in' to help you find the useful
stuff. Got a Swiki reference? The morphic tutorials only partially cover
this.

For example, how about a howto/FAQ:

``If you want to create a toplevel window, do XXX.  To get a Form to draw
to it do YYY. You can use operations in ZZZ for extended drawing
functionality.''

Which actually were questions I was going to ask in a week or two.
Well, the XXX part at least. Code browsing answers YYY and the smalltalk
book covers ZZZ.


Thanks for the reply.

Scott


--
No DVD movie will ever enter the public domain, nor will any CD. The last CD
and the last DVD will have moldered away decades before they leave copyright.
This is not encouraging the creation of knowledge in the public domain.