RBSqueak - what's next

Andrew C. Greenberg werdna at mucow.com
Tue Dec 4 15:35:49 UTC 2001


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





More information about the Squeak-dev mailing list