On Tue, Nov 22, 2011 at 11:37 AM, Chris Muller <asqueaker at gmail.com> wrote:
> Have you considered fixing / augmenting the general capabilities of
> ToolBuilder with the needs of OB?

Yeah, that was my original intention, but I couldn't get it done in
time for the 4.3 feature freeze.

> Seems like needing to know the selection at any time is something that
> any TextMorph widget should be able to provide!  I'm pretty surprised
> it doesn't already.

Agreed. There's a bit of a hack in MenuMorph to get around this
problem; look at the senders and implementors of #perform:orSendTo:.
I've implemented a better solution in PluggableTextMorphPlus that
works pretty well for OmniBrowser's needs. I'll commit to trunk after
4.3 is out.

> Are there very many more cases where ToolBuilder falls short?

 Well, a few:

One thing that was just impossible was implementing a good completion
dialog. If you choose "find class" in the standard browser, a dialog
box comes up that lets you type a class name and shows you possible
matches as you type. In the standard browser this is implemented by
ListChoose (Morphic-specific). OmniBrowser does something similar for
finding classes and several other operations. For a dialog like that
to work well, it has to be open ready to receive input and respond
instantly, and get out of the way when it's done.

ToolBuilder doesn't provide a way to have the search field
automatically accept the text every time it changes. There's no way to
direct the keyboard focus to the search field when the window opens.
There's no way to send all keystrokes in the window to the search
field. There's no way to position the window near the hand. Even
closing the window when you have an answer is tricky and hackish.

ToolBuilder lists don't support icons. Apparently Pharo has a version
of ToolBuilder with icon support, so I'm going take a look at
harvesting that.

There's no way to create a scrolling panel. I need this for browsers
with dynamically added columns - eg the chasing browsers. This one I
can work around, but I don't know how usable it is.

This is more Morphic than ToolBuilder, but right now I'm wrestling
with the way SystemWindow insets panes and inserts proportional
splitters. It works fine for the stock browsers, but it's tricky to
get reasonable behaviour for the generality that OmniBrowser provides.
(I'll probably have at least one bug fix for 4.3 here).

There are probably a few more that I haven't encountered yet.

> Does your option 4 mean you need to chanse existing base methods?  You
> said, "add" the functionality so maybe you mean only add extensions.
> If that is the case, I think that's fine.  However, if you meant the
> former, then my concern about option 4 would be that it would pretty
> much guarantee a continued "dichotomy" between ToolBuilder and OB.  I
> like a lot of OB, but wouldn't be able to use it if I had to abandon
> the highly-productive windows we have now..

Option 4 would involve changing base methods, but wouldn't change the
existing behaviour. For example, PluggableTextMorphPlus currently
raises an error if you give it a getMenuSelector with more than 2
arguments. My fix to the text selection problem changes the menu logic
to allow 3-argument selectors - if you give it one, it'll send you the
text selection in the third argument. Shouldn't break anything.

In any case, Option 4 would be temporary, since the changes would go
into the trunk for inclusion in Squeak 4.4. I definitely don't want to
continue the dichotomy; the whole point of using ToolBuilder is to get
rid of it.

I'm going to see how far I can get with Option 4, but if I have to
cheat a bit by tweaking the Morphs directly (Option 1) I will.

Colin