SqueakMap Package Loader UI

> On Nov 24, 2006, at 1:10 PM, Andreas Raab wrote:
>>> - 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. So the search button  
>>> had to go, because ToolBuilder can't do that easily.
>>
>> Yes, that is true.
>
> Maybe it can be fixed by detecting that a model is a Spec and then  
> remembering that in an IdentityDictionary and then mapping it to  
> the output. I don't know how feasible that is, but it's seems like  
> it'd work reasonably.

> Brian Rice wrote:
>> It's time for me to backtrack again - I was wrong about this in  
>> the general sense. There *is* a Dictionary mapping widgets to  
>> outputs. More specifically, it maps the names of widgets to  
>> outputs, which is good enough, and accessible via widgetAt:
>> (ifAbsent:). I missed this because the abstract ToolBuilder class  
>> doesn't have a dictionary instvar, just the protocol, even if all  
>> concrete subclasses use it. Also, there is no code making use of  
>> this feature, but it works fine.
>
> If you want to push this up to ToolBuilder, feel free to send me a  
> patch. Or even easier, get yourself an account on squeaksource.com  
> and I'll add you as another developer.