SMLoaderPlus and ToolBuilder (was Re: SqueakMap Package Loader
UI)
Andreas Raab
andreas.raab at gmx.de
Fri Nov 24 21:10:46 UTC 2006
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
More information about the Squeak-dev
mailing list
|