SMLoaderPlus and ToolBuilder (was Re: SqueakMap Package Loader UI)
Brian Rice
water at tunes.org
Thu Nov 23 21:57:08 UTC 2006
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
More information about the Squeak-dev
mailing list
|