Brian Rice wrote:
> 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.

That's a funny comment given how little exposure I had to Java ;-)

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

> - The other issue was that I couldn't add a help text to the text field. 
> Why isn't #help an attribute of every specification element type? Who do 
> I bother to get that change made to ToolBuilder? Every object in Squeak 
> needs the ability to explain itself, even if the user turns all of it 
> off (smarter help-showing strategies would probably make it less 
> intrusive).

The best person to bother would be me. And I agree that text fields 
should have a #help to be used with it. If you post a fix to mantis just 
assign it to me.

> - Trying to layout the search pane *with* the buttons on the top bar was 
> an exercise in frustration. Passing a fractionally-specified frame 
> rectangle seems like it should be straightforward in semantics, but I 
> couldn't get any layout to happen that corresponded with my intuition, 
> and I still haven't figured out how exactly the builder code deals with 
> those frame specifications. So I moved the search field back to the 
> package-list pane. What am I missing?

Not sure. The layouts should work just as intuitively as you thought. 
Can you send an example that didn't work the way you expected it?

> PluggableTreeSpec is strange. It took me a while to figure out what kind 
> of protocol I had to make to populate it, or what objects had to respond 
> to the selectors (sometimes it's the item wrapper object, other times 
> the model).

Actually you seem to be misunderstanding something more fundamental 
about the tree widgets here. From the programmer's point of view there 
is no "wrapper object" (this is only part of the Morphic implementation 
but doesn't exist in Tweak for example) and the messages are *always* 
sent to the model and *always* pass the item along to query for. So, for 
example, to query the children of an item the tree sends the 
<getChildren> selector, a one-argument message passing the item 
alongside it. This avoids the need for any of the wrappers. For example, 
instead of using a hierarchy of FileDirectoryWrappers you would use 
something like here:

MyFileList>>getDirectoryRoots
   "Answer the roots for the directory tree"
   ^Array with: FileDirectory root

MyFileList>>getChildrenOf: directory
   "Answer the children of the directory"
   ^directory directoryNames collect:[:str| directory directoryNamed: str]

MyFileList>>getLabelOf: directory
   "Answer the label for the directory"
   ^directory localName

etc. Again, the idea is to abstract away the current (Morphic) 
implementation of trees and replace them with a set of pluggable 
selectors that can be used to query for the relevant properties.

> Perhaps there should be a default protocol, a default name 
> for most selectors and a little documentation saying what those are, and 
> that they're override-able in the constructor or mutator methods. (This 
> idea actually reminds me of Rails, and probably rightly so, as they are 
> both builder patterns.) Particularly odd-seeming is how to update the 
> selection programmatically, as happens when the search pane is used - if 
> I call "self changed: #selectedItemWrapperPath", the selector that the 
> package list is watching, it deadlocks trying to redraw until I hit 
> <alt-period>, so I've left that out and the pane doesn't update on its own.

Yes, you'd be interfering with the Morphic implementation in this case. 
What you want to use is <getSelectedPath> selector from the 
PluggableTreeSpec, e.g.,

MyModel>>getSelectedDirectoryPath
   "Answer the path for the currently selected directory"
   ^selectedDirectory pathParts

and then:

MyModel>>changeDirectoryTo: newDirectory
   selectedDirectory := newDirectory.
   self changed: #getSelectedDirectoryPath.

Cheers,
   - Andreas