patch for textbox beginnings

[Timmy Douglas]

Brian Rice <water at tunes.org> writes:

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

ok it makes more sense now, thanks.

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

ok

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

The way the SceneElement is defined now, handle: on SceneElement
traits doesn't do anything so it sort of just ignores the event. It's
sort of convenient to only have one handle function but I guess stuff
could get lost in the process without an error being thrown. Right now
I have that overriden to print to the console so it is interesting to
see what gets thrown out.

Another thing is that the person who defined the PassPointerToChildren
event made it check that: se inputHandler == se ifFalse: [pass it].
So it gives the impression that I need to make another object and
specialize the handle: functions on that instead of specializing on
itself. It sounds sort of like a pain to me and I'm not really sure of
the reasoning behind requiring it. Any idea?

The problem with this is that keyboard events don't have mouse
coordinates afaik. I suppose I could look up the current position of
the mouse, but I don't want this to be like squeak where when you want
to type into a textbox, you often have to have the mouse right over
the box, otherwise the input won't go there. Or at least I think it
should be up to the user if the focus follows the last click or if it
follows the mouse, etc. The other thing is that I'd like it so things
would somehow request focus no matter where they pop up, like a
FillInTheBlankMorph might. I think for it to work like this, I'd have
to manage the morph(s?) currently in focus, but with MouseMotionEvents
coming in like 5 times a second, it might mess things up... but I'm
not really sure...


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

As long as defining the layout/commands and changing things
dynamically is easier than clim's define-application-frame, I'll be
happy with it. I always found that painful to use.

In clim, you'd often be able to get the value of the app object with
*application-frame* or whatever, is there a good way to have that
easily accessible like that in slate? I guess this is assuming there
could be more than one app object, otherwise it'd be trivial.

Well, anyways, I have a better idea of what to do now, thanks.