patch for textbox beginnings

[Brian Rice]

On May 31, 2006, at 7:16 PM, Timmy Douglas wrote:
>   I also started a file called fundamental-mode. This would ideally  
> be a
>   command list that takes basic key presses and sends the
>   textbuffercommands to the buffer. Right now though I have no idea  
> how
>   the defined CommandMap is supposed to work (it's a dictionary but  
> what
>   maps to what? what does translators do? what kind of object is an
>   accelerator? etc)

CommandMap roughly corresponds to Command Tables from CLIM 2:
http://www.mikemac.com/mikemac/clim/commands.html#27.2

Unfortunately, the command-table specification is inconsistent and  
confusing. The idea is merely that there would be a data-shaped (as  
opposed to method protocol-shaped) way of linking input patterns to  
behaviors. Feel free to work creatively with this.

One abstraction I've tossed around is to use the Stream idea as an  
event processor component; since Slate Streams can be piped and  
handle all collection protocols, it's more feasible than for regular  
Smalltalk, even if slower. ;) Also note that nextPut: could be  
overridden per the second argument position's type as well as the  
first, leading to WriteStreams that discriminate based on input.

> The next step would be figuring out how to send the keypresses to the
> right morph and deciding how that should be done. Maybe someone can
> give me an idea here.

There are a couple of different options.

Top-down: basically the "handle:" method for aggregates obviously  
looks at the coordinates of the source object of the event (often the  
event contains those) and compares them with the children and pass  
them downwards if they "want" to handle them. This idea of "want",  
Squeak Morphic makes you write a separate "handlesFooEvent: evt ^  
true" method for every "handleFooEvent: evt", which is awkward; in  
Slate, it'd at least be "handles:" vs. "handle:" but the same idea.  
It could also be indicated by running "handle:" and checking the  
return value for some special symbolic object (say, "Unhandled") that  
the default method returns. I've also considered using an abnormal  
exit control flow setup, but that's a bit abusive since it might lead  
to unexpected condition-handling effects (anyone should feel free to  
play with this idea, though, just to see).

Bottom-up: this requires just digging down to the bottom-most scene  
element as soon as an event object is generated, and checking whether  
the element "wants" to handle the event on its own and then doing so  
or handing it up to the parent.

Maybe you were thinking about a different level? This is worth  
discussing if you're not sure where you want to go with it or if  
there are more complex specific issues. Both of these methods have  
deficiencies.

> Then I need to figure out how the CommandMaps should work, where the
> command message/undo rings should be placed, and then we'd probably
> have a functional textbox.

That's an interesting question about command undo/redo rings. I'd  
considered for example that application objects (roughly being MVC  
models at the macro-level vs. presentations at the micro-level) would  
be event stream processors, and different such applications would  
then invoke the event-propagation strategies (the above top-down vs.  
bottom-up and probably others) depending on how they were intended to  
be used.

How does that strike you, conceptually?

--
-Brian
http://tunes.org/~water/brice.vcf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060606/d73011b0/PGP.pgp