Daniel -- can you give the URL again? Last time I tried to download RB, I couldn't get the fileIns to work, and gave up without giving it a serious think. I'd really like to have RB in Squeak, so I'm game to try again. If there is a magic sequence, I would appreciate knowing how to load up the changesets into, say, a virgin image.

On Saturday, September 8, 2001, at 02:40 PM, danielv@netvision.net.il wrote:

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