Squeak textbox and events.

Scott A Crosby crosby at qwes.math.cmu.edu
Sat May 12 22:17:27 UTC 2001


The more I see the squeak textbox, the more I wish for the TK one.

I'm new to squeak, so may be I'm mistaken.. But its seeming to me that the
TCL textbox has a lot more flexibility and power than what squeak is
fielding.

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!

Similarily, the other uses of it appear to have the same flaw.

So, maybe borrow a few things from TK?

--

The TK textbox stores everything on a B-tree... It supports an unlimited
number of marks, an unlimited number of tags. Widgets and images may be
inlined within the text. Tagged text may be given style attributes to
change its color, font, stipple, size, underline, overline, offset, etc.

A mark is a named point in the text. This point remains static despite
editing. It's useful for implementing the cursor, named anchors, etc.

Tags are possibly overlapping named ranges of text. One range of text may
have multiple tags, and any range may be tagged independently of other
tags. Furthermore, a tag may tag multiple disjoint ranges of text.  Other
than supporting different display styles, tags also support custom events
for mouseclick, Enter, Leave. They also support finding the next/previous
range of text thats tagged with the current tag.

So, one could make the textbox for coding tag all compiler-generated error
text with 'CompilerOutput', and automatically delete it upon the attempt
to resave it.


Its efficient.. I have a logfile colorizer that can have dozens of 100kb
files, with two dozen different tags, and tens of thousands of ranges of
tagged text.. And everything moves in realtime.

--

TK also has another nice architecture, the event-handling architecture.
Events may be attached to either widgets or as event tags:


event .foowindow <Enter>   [[ BLOCK of what to do; hilight it maybe? ]]
event TextBox <Keypress>  [[ BLOCK that inserts the keypress into the
                               textbox]]
event TextBox <Mouse-Drag-2> [[ hilight and mark the text as selected ]]


eventtags are sets of event-matchers like the above that are collected
into sets because they are shared between widgets.. Event handler blocks
get the event object that triggered the event. (which will include the
widget the event was destined for)


When a widget recieves an event, it sends it to all of the eventtags it is
marked to use. This usually includes its own name as an eventtag, its
toplevel parent window (for example, the toplevel window may have
events that trigger on command shortcuts), its wiget name ('Textbox'
'Button') and the root object.

This is a very flexible scheme. For example, the current behaivor of
'stepping' could be implemented by creating an event called 'step' and
every 100ms, passing the event to any morph that was triggered to match on
it.

Its also powerful; one can have, for example, DND-Enter events if we're in
DND and the hand is above us, so we can behave reasonably..

Everything is introspective. New events can be defined and invoked.

I don't know morphic that well, but from what I've read here, it doesn't
have this type of thing. If there's a big design decision for why, can
anyone explain.


--

As I now view TCL as a greatly deformed implementation of Smalltalk, its
surprising to me that Squeak appears so shockingly inferior in these two
aspects. This may be an artifact of Squeak not having block closures;
they're really critical for this type of event-handling system...

Any thoughts?


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.






More information about the Squeak-dev mailing list