So, I've spent a day with the ToolBuilder. I'm mostly impressed, but there are some issues I'll describe as I explain what I've made.
Rev. 44 in the repository on my site (below) has the new functionality in mostly-working order: http://briantrice.com/Squeak/SMLoader-btr.44.mcz
When the package loads, there are SMLoader and SMLoaderPlus. Both of them in their class-side #initialize methods, check for the presence of ToolBuilder, and SMLoader registers itself if ToolBulder isn't present, and otherwise, SMLoaderPlus registers itself. I think this setup will help publish SMLoader without problems in older Squeak versions. I still need to test this in various ways.
Here is a screenshot of SMLoaderPlus: http://briantrice.com/Images/Squeak/SMLoaderPlus1.jpeg
First, I'll state what I liked about ToolBuilder: it removed some grimy nuts-and-bolts-ness from the application code. I didn't have to specify dependents except by saying which selector a given widget should pay attention to. It was easy to specify buttons and their enabling/disabling. ToolBuilder uses some reasonable defaults for a lot of rendering, so my app looks like other ToolBuilder-using apps without any work, and I don't have to maintain that. And it'll presumably work on Tweak and even MVC if that part gets fixed. Despite the long rambling after this, I endorse ToolBuilder and think it is a good kind of way forward.
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. So the search button had to go, because ToolBuilder can't do that easily. - 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). - 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?
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). 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.
Finally, there doesn't seem to be any documentation on ToolBuilder that is better than the source of the apps created as examples on SqueakSource (not in the image). I learned the most when I found and loaded them. But the classes all have basic, informative comments.
On Nov 22, 2006, at 1:37 AM, Brian Rice wrote:
I fixed up some of the problems with the previous layout and buttons and added package-specific toolbar buttons: http://briantrice.com/Images/Squeak/SMLoader2.jpeg
Monticello packages (rev. 40 is the relevant one) at: http://briantrice.com/Squeak/
- Installed packages and releases are now marked in bold.
- All the main buttons that people need to see are in a button-bar
that works.
- The code is set up so that if there's a better way (more
standard) to construct the toolbar, it will be easy to refactor to that form.
- The search bar is obviously marked as such.
- Menu entries are more succinct, which means people might actually
read them (balloon help explains so I allowed them to be terse).
That seems like it's Good Enough to not put people off.
Comments? Suggestions? Rants?
-- -Brian http://briantrice.com