multi-widget accept/cancel (was Re: SMLoaderPlus and ToolBuilder)

Brian Rice water at tunes.org
Sat Nov 25 01:09:11 UTC 2006


On Nov 24, 2006, at 1:04 AM, Lex Spoon wrote:

> Brian Rice <water at tunes.org> writes:
>> The search pane... hm, this gave me some grief. So, in this builder
>> design pattern, you construct a tree of specification objects, pass
>> it to the Builder object and tell it to build: them. This seems
>> rather Java-inspired, but that's beside the point.
>> - One issue I had was trying to recreate the "Search" button that in
>> the original, took the search field as its model and called #accept
>> on it to kick off a search. In a builder interface, you can't do
>> this, because you only get the specification objects and not the
>> output. In fact, you're not supposed to be able to access the output.
>> I thought about work-arounds, but they all involved propagating the
>> search field text to the model on every keystroke and then having the
>> button call a method on the model that uses that, or making a
>> trampoline in the model that the search field would watch... except
>> that it can't do that.
>
> This I think is a mis-designs in the Smalltalk accept/cancel style.  I
> like accept/cancel in general, *except* that it should really apply at
> the level of an entire pane [1], not at the level of individual  
> widgets.

I agree about this perspective.

> When I write Squeak dialogs by hand, the best approach I have found is
> that each entire pane has a variable with a list of individual widgets
> that need to be accepted before the pane can do its work.  Then, I
> have a method that iterates through this list and calls acceptIfNeeded
> (or whatever it is called).  Then, I call this method at the beginning
> of every method that observes the input of those fields.

Huh. That does seem like a decent way to get the job done in morphic.

> I implement this pattern repeatedly.  It would be a candidate for a
> framework such as ToolBuilder.  (Of course, if ToolBuilder has another
> approach to this problem, then just as well!)

ToolBuilder doesn't do this - it just offers PluggableInputFieldSpec  
which is just a text input field. The spec could conceivably be  
extended with an action button and/or title, but it doesn't seem like  
an easy way to go.

UIManager of course has its dialog protocol, which to me sounds like  
a ChoiceSpec or something similar, but it's not the same as offering  
a non-modal open-input choice, or even a modal set of open-(or not)- 
input choices. Certainly an InputSpec makes sense which would come  
with its own way to specify validators and sub-validators.

> For your search example, the model object behind the search-area
> pane--or indeed the search-area pane itsealf--could have a variable
> pointing back to the text widget where the user types in the search
> phrase.  Then the "search" method would accept this pane before doing
> the actual search.

The problem is that the model (that specifies what it wants built)  
only holds on to the /spec/ of the widget, not the widget itself. The  
point of the build process is to decouple that model from the actual  
structural details of the output, focussing only on the spec. If I  
reach into the "window" variable output and grab the specific morph  
in question, I've coupled my app not just to Morphic but to the way  
in which the ToolBuilder generates Morphic widgets.

But maybe what you're saying is that there needs to be a separate  
model, perhaps generated for every input field/set. That's  
interesting, but I don't know what to do with that idea.

> By the way, always remember when doing this that an "accept" can fail
> on invalid input!  These methods should return a boolean to indicate
> whether the accept was successful, and if it was not, the calling
> method should silently quit.

Yeah, that's a good point.

> [1] I started to write "window", but really what I write just applies
> to contiguous portions of a window used for one purpose.  There is a
> contingent of Squeak UI designers who prefer to have big
> multi-function windows instead of the more classical single-purpose
> windows.

There should probably be a term neutral to pane/window which  
specifies an activity or something. I'll give it some thought.

--
-Brian
http://briantrice.com

-------------- 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 : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061124/24faff6a/PGP.pgp


More information about the Squeak-dev mailing list