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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061123/c7b71588/PGP.pgp