Incorporating OmniBrowser (was Re: Lessons learnt from been an integrator)

Colin Putney cputney at wiresong.ca
Fri Sep 10 22:54:00 UTC 2004


On Sep 10, 2004, at 4:23 AM, danielv at tx.technion.ac.il wrote:

> If you release (an alpha) in the next day, we can test it at
> CampSmalltalk and maybe help along.

Ok, this isn't quite a full release, as I haven't posted on SqueakMap 
and don't have time to figure out SAR packaging tonight, but here it 
is. You'll need Monticello loaded to run the tests.

http://monticello.wiresong.ca/ob/OB-Standard-cwp.17.mcz

The major changes are:

The old OmniBrowser package has been split into three: OmniBrowser is 
now just a base library with no actual browsers implemented. 
OB-Standard contains the standard code browsers, and OB-Filesystem 
contains the file browser. I've left the file browser alone since it 
was broken out.

The code browsers no longer use contexts as an abstraction layer, now 
OBCodeNode and descendants manipulate the image directly. This also 
means that OBClassReference is mostly gone. (It's still used by 
OBMethodVersion, but that actually makes some sense even without 
contexts.)

The package browsers are gone.

There's now a background process that catches events from the 
SystemChangeNotifier and updates browsers. This is still a bit buggy. I 
expect it's because I'm drawing from a process other than the UI 
process.

Browser window titles are now configurable and code browsers use this 
to display the currently selected class.

The optionalButtons now behave more like the default browsers - there's 
a fixed set of buttons that get enabled and disabled as the browser's 
selection changes.

OBBrowser has been refactored to make it easier to create subclasses 
with specific configurations. OBSystemBrowser and friends use this to 
make it easier to open browsers on specific classes, methods etc. I 
haven't yet implemented compatibility methods such as #fullOnClass:

There are now some basic tests for node ancestry.

I've begun a refactoring of actions, to pull them out of the node 
classes and into Actor classes of their own. OBCategoryActor provides 
an example of how this will work - it replaces duplicate 
implementations in OBClassCategoryNode and OBMethodCategoryNode.



Still to do:

- refactor more actions, with tests
- tests for drag and drop
- create reorganization actions
- create a message search browser

- removing a method in the chasing browser causes a syntax error
- make the browsers update properly

Feedback appreciated, as always. I'll do a proper release to SM "soon."

Colin




More information about the Squeak-dev mailing list