[UI] ToolBuilder

[Colin Putney]

On Sep 9, 2007, at 8:42 PM, tim Rowledge wrote:

>> By making the view-model protocol to be different for each view,  
>> the model can react differently to different view. In OmniBrowser  
>> I found that even this level of flexibility wasn't enough. I found  
>> I wanted a variable number of views, which pluggability couldn't  
>> accommodate.
>
> Hmm, I'm not sure I see how pluggability would let you down here.  
> Can you remember any details? I'm curious.

Well, the standard Browser has 4 lists, and it assigns a different  
selector to each of them to say, get the list strings to display. The  
first pane uses #systemCategoryList, the second one #classList, the  
third #messageCategoryList and the last one #messageList. You have a  
different selector for each view, and the model can respond  
appropriately to each one.

But now lets say I want to implement something like the chasing  
senders browser in OB. It starts with a single list of methods that  
send a particular message. Click on one, and it adds another column,  
showing the methods that send the message you just clicked on. Click  
on one of those, and you get another list - the senders of *that*  
method, and so on for as many clicks as you care to make. To get that  
to work, I need more do more than differentiate between a few  
different but pre-defined lists the way the regular browser does. I  
need the selector from the previous list, or at least the index of  
the list so I can look the selector up. To do this with the existing  
pluggable views, I'd have to do something like assign the views a  
sequence of selectors, like #getList1, #getList2, #getList3 etc, and  
do some DNU tricks to decode the implicit argument. Yuck.

>> So I went back to the one-view-per-model pattern, with the main  
>> model holding a collection of sub-models and communicating through  
>> them.
> That can work too; in fact it's pretty much what Tweak formalised  
> (a proper class of graphical model as well as the application/ 
> domain model etc) and really it is what the Browser class is/was  
> fumbling toward. I even wrote a paper on it in the dark ages around  
> '88 or so.

I should probably learn more about Tweak. I gave it ago when it was  
still pretty new and couldn't make heads or tails of it. Now that OB  
supports multiple GUI libraries, there's no reason not to support Tweak.

Colin