Daniel, just wanted to say that it's great to see someone actively
maintaining and working on the Refactoring Browser port for Squeak.

I haven't personally had time to try out your latest version yet, but I
will sometime soon.  Your description of the Navigator/CodeTool/etc, and
what you're doing with them, is helpful.

I would like to add Whisker as an alternate UI to the RB at some
point... I may try to work on that at OOPSLA since there will likely be
RB-knowledgeable people there.  (With the Navigator, are you saying that
you are going to leave it out for now because Browser handles its duties
and to keep things simple, but that you'd probably need to have
Navigator to support multiple UI's including Whisker?)

Also, I am on the fixes review group, but mostly we're currently working
on streamlining the incorporation of smaller fixes and enhancements.
The RB is a pretty big item, which would probably be mostly up to SqC to
decide to incorporate.  (The fixes review group may eventually expand
its duties to look at larger items, I don't know.  Also, the notion of
the "base image" will probably change a bit once a modularity system is
in place.)

Anyway, your current idea of separating and submitting a minimal set of
base image changes seems like the right thing to do for now.

Keep up the good work,

- Doug Way
  dway at riskmetrics.com


---------------------------------------------------
From: danielv at netvision.net.il
Subject: RBSqueak - what's next
Date: Sat, 8 Sep 2001 21:40:21 +0300

First of all, I've seen no bug reports. Is it perfect? is it unusable? 

Anyway - I've been looking at the RBPort as it stands, thinking about
what's needed to move it to the next state - from Beta code to something
that could be folded into the base image.

As an aside - Eventually putting the RB in the base image is not my
call, and it's not fair to ask people to make that call before I've made
the changes that are neccesary. OTOH, if they (changes review team/SqC)
should pitch in with advice/guidelines, I'd be inclined to take them
into consideration...

Back to track. First, what we have now -

The port currently has four files - 
* my trivial, insignificant ClassBuilder fix(?)
* The RBModel changeset (including mostly new classes, and some small
and not so small changes to base classes)
* The RBUI changeset (including lots of empty VW classes that have
either been replaced with the morphic equivalents or are simply not
being used now)
* and the CS3 work changeset, addin and modifying to the classes defined
in the above.

There are already some contributions sent on the list and to me
privately that are mostly further modification of the package's classes.
Stephen B. Wessels aesthetic updates are among those, but include a
dependence on the variables pane (which, btw, I like, and could itself
make better use of the RB...). 

These make it more important to clean up this package, in order to stave
off chaos...

As I see it, the main requirements to being able to add the RB to the
main and SWT images (or for the package to stay live if it isn't) are-
* Changes to base classes are minimised and separated out to changesets.
Preferably, for the ones that are positive to be accepted into the
image, separate each change to make it easier for the review team to
decide on each.
* Classes that are not being used should be discarded. This raises
questions about the functionality they represent, but that's a worry for
later.
* New classes should be packaged as modules, that is, no class/method
additions/removals, just definitions of code that's being used.

I'm going through this sorting process now.

What I'm discarding (with class comments/my comments)-
* Navigator (plus subclasses and collaborators)
Navigator is an abstract class that defines the interface that displays
the classes/methods of an BrowserEnvironment. Its subclasses define what
actions can be taken for the different selections.
* CodeTool (plus subclasses and collaborators)
CodeTool is an abstact class represents the tools that can appear when a
user has selected an item (e.g., a class) using the navigator. These
tools are dynamically switched depending on current selection.
* OMT-Diagram (a whole category)
A graphical way of viewing a class in a hierarchy diagram.

CodeTool and its subclasses factor out the multiple uses and meanings of
the bottom pane of the browser, splitting the functionality into
separate classes. Would make it easier, for example, to add a new tool
for viewing the new XML UI Spec in a hierarchy widget. It could be used
to factor out showing the code in alternative ways, like SyntaxMorphs,
and so forth.
So this is a pretty useful concept to have, eventually, in all our
browsers.

Navigator allows one to isolate the state of the Browser (what are we
browsing, what's selected). It's subclasses give the shape of the
browser - some look at one class, or one protocol, and so forth. The
different types of Environments know what navigator should be used to
look at them.

Right now our poor Browser and RefactoringBrowser take on all these
responsibilities, making them, well, slightly obese?

Another recurring theme in doing the glue code for the RB UI to call the
RB model, was that this requires some additional responsibilities which
the UI might not be best suited to carry. Right now the UI has to know
that after doing an Extract Method,it should refresh the code pane and
the messages list, and refocus on the method with the same name as
before (not the same index..).

Assuming someday we'll want to integrate the RB into alternative
browsers like Whisker, there's no real reason why that should hard coded
in yet another UI...

So that's another refactoring that needs doing at some point.

I'd like your thoughts on how the RB work should proceed and
specifically about it's link with other Browsers...

Daniel