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