RBSqueak - what's next

danielv at netvision.net.il danielv at netvision.net.il
Tue Dec 4 21:11:23 UTC 2001


Hi Andrew.
I've just tested the install script on a fresh 4542 image, and it seems
to work fine.
It's where Stef said - there's an install script.

There's a commented portion to integrate the RB as your default browser
and put both it and the Lint in the Flaps (thanks Ned!). 
If you want to use it, you need to add a period to the last line before
it, and reinit your Flaps after installation.

Let me know about any niggles you find, in the installation or
elsewhere...

Daniel

"Andrew C. Greenberg" <werdna at mucow.com> wrote:
> 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