OmniBrowser and ToolBuilder

Hi folks,

Lately I've been working with Lukas Renggli on a new version of
OmniBrowser. The main focus has been on cleaning up and isolating
platform dependencies so that we can have a single version that works
well on both Squeak and Pharo, while fitting comfortably into each
platform's idioms. That part of it has been quite well.

For proper integration with Squeak, I've been trying to get OB
building its interface using ToolBuilder. It *mostly* works, but there
are some areas where ToolBuilder doesn't provide the functionality
that OmniBrowser needs. I had planned to extend ToolBuilder a bit with
the additional functionality that OB needs, but that turns out to be
more work than I anticipated, and I wasn't able to get it done before
the 4.3 feature freeze. So, given the constraint of working with the
Squeak 4.3 feature set, I'm not quite sure how to proceed.

Here are some of the options:

1) Abandon ToolBuilder and just deal with Morphic directly. This is
what OB has historically done, and I'd just be updating the old
Morphic code to fit better into modern Squeak conventions. There's no
longer any need to have this code work on Pharo, since Lukas is now
using a separate Polymorph-specific widget package on Pharo.

2) Use ToolBuilder where possible, but customize its output. This
misses the point of ToolBuilder, since it means OB won't be able to
work with MVC, but at least it reduces the chance that OB will get
left behind if someone adds a feature to ToolBuilder. It is a bit of
"worst of both worlds" situation.

3) Use ToolBuilder, and just accept that not all the features of OB
will be available until they get added to ToolBuilder. I'm not sure
how much graceful degradation I can acheive, but it might not be too
bad, and it'll give us (me) motivation to improve ToolBuilder for
Squeak 4.4.

4) Have the OB installation process patch the base image to add the
needed functionality. That would be the cleanest in terms of the OB
code, but has the potential to break other packages that users might
want to load.

I'd really like to make this next release a solid toolset for Squeak,
and fix a lot of the little annoyances that cause Squeakers to avoid
it. Lukas' refactoring stuff is really excellent, better than the
VisualWorks refactoring browser IMHO, and I want to make it palatable
to more people in the Squeak community. I'm leaning towards option #1,
because I suspect it's the mostly likely to achieve that, but I
thought I'd put it out there and ask the community for advice. So, how
important is ToolBuilder? What options am I missing?


Cheers,

Colin

On 20 November 2011 08:56, Colin Putney <[hidden email]> wrote:
What options are missing from ToolBuilder? Is it just a case of
missing specs (+ Morphic backing) for some set of widgets?

I really like ToolBuilder: it lets me see the skeleton of the UI - and
alter it - without the steep Morphic learning curve that's so far put
me off learning it.

frank

On 11/20/11 6:56 AM, "Colin Putney" <[hidden email]> wrote:
> I had planned to extend ToolBuilder a bit with
> the additional functionality that OB needs, but that turns out to be
> more work than I anticipated, and I wasn't able to get it done before
> the 4.3 feature freeze.

So this extended functionality comes in near future Squeak 4.4.

> 3) Use ToolBuilder, and just accept that not all the features of OB
> will be available until they get added to ToolBuilder. I'm not sure
> how much graceful degradation I can acheive, but it might not be too
> bad, and it'll give us (me) motivation to improve ToolBuilder for
> Squeak 4.4.


And add some logic for when we updated Squeak also updated OB.

OB becomes default at some point IMHO.

Very thanks to you and to Lukas for working in OB.

Edgar

On Sun, Nov 20, 2011 at 12:56:26AM -0800, Colin Putney wrote:
This (option 4) sounds like the right thing to do. Toolbuilder is
not really complete at this point, so it seems likely that whatever
you need to implement for OmniBrowser will turn out to be the right
thing to do in the long run. I am not aware of any other projects
in development that would lead to conflicts, so if you add ToolBuilder
extensions to OB now, adopting these in the base ToolBuilder package
later should be no problem.

>
> I'd really like to make this next release a solid toolset for Squeak,
> and fix a lot of the little annoyances that cause Squeakers to avoid
> it. Lukas' refactoring stuff is really excellent, better than the
> VisualWorks refactoring browser IMHO, and I want to make it palatable
> to more people in the Squeak community. I'm leaning towards option #1,
> because I suspect it's the mostly likely to achieve that, but I
> thought I'd put it out there and ask the community for advice. So, how
> important is ToolBuilder? What options am I missing?

Thanks for doing this. Improvements to ToolBuilder would be welcome, and
having them driven by the requirements of a real application (OB) should
help ensure that the right features are implemented.

Dave

On 2011-11-20, at 1:15 AM, Frank Shearar <[hidden email]> wrote:

> What options are missing from ToolBuilder? Is it just a case of
> missing specs (+ Morphic backing) for some set of widgets?

No, the widgets all seem to be there. What's missing is configuration
options, and in some cases, capability in the Morphic widgets.

For example, a bunch of refactorings operate on the current selection
in the text pane. (eg. Extract Method.) Pluggable TextMorphPlus
doesn't give the model any way to find out what the selection is when
the building the context menu, so it can't decide what refactorings
are applicable.

Colin

On 11/20/11, David T. Lewis <[hidden email]> wrote:
I like option 4 as well.



My thanks as well. This is great news that you worked with Lukas to
create a common code base and are working on adaptions to Squeak and
Pharo.

--Hannes


> Dave
>
>
>

Have you considered fixing / augmenting the general capabilities of
ToolBuilder with the needs of OB?

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.

Are there very many more cases where ToolBuilder falls short?

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..

 - Chris

On Sun, Nov 20, 2011 at 12:37 PM, Colin Putney <[hidden email]> wrote:

On Tue, Nov 22, 2011 at 11:37 AM, Chris Muller <[hidden email]> 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