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
|