[Setools] OmniBrowser Roadmap
Colin Putney
cputney at wiresong.ca
Sun Oct 22 20:25:51 UTC 2006
Hi folks,
I know there are a few people out there who are using OmniBrowser for
their own projects and I thought I'd post here about the things I'm
working on and where I'd like to see OB go in the near future. So
here's a list of mini projects, arranged rough in order of short-term
to long-term, though this ordering is by no means set in stone:
Extensibility
----------------
One of the biggest problems in the current design is that it's quite
difficult to create a package that extends the standard browsers.
This stems from the way Actors/Actions are constructed, by a single
#actions method on an actor, which is attached to the metagraph. It's
impossible to either add actors to the metagraph or add actions to an
actor without overriding methods in OB-Standard.
In recent versions of OB, I've been gradually converting the
functionality of Actors into what I'm calling Commands. (The code to
date actually uses the name "services" but I'm about to do a grand
renaming, as it's actually quite different from the services used in
Squeak 3.9). To add a command, all you have to do is this:
- subclass OBCommand, and implement at least #label, #isActive, and
#execute.
- add a method to a browser class with a selector that begins with
'svc' and returns your command class
This should allow people to easily extend the standard browser with
new commands. I haven't figured out a way to make metagraphs easily
extensible, but I'm not sure that this is a real problem in practice.
If you want to change the way browsers navigate, it creating a new
browser probably isn't a bad idea anyway.
Web Interface
-------------------
Another project I've got going is to have a web-based UI for
OmniBrowser. It's quite experimental, but promising. If it works out
well, it could serve as a basis for other UIs like Tweak, and enable
a single OB codebase to have the correct Morphic look on different
versions of Squeak.
Refactoring
----------------
Once all the existing functionality is converted to commands, I'd
like to create refactoring commands.
Removing Optional Buttons
-------------------------------------
One of my goals for OmniBrowser 1.0 was to duplicate the
functionality of the legacy browsers pretty much exactly, with only
minor improvements around the edges, like the chasing browsers. For
the next major release, I'd like to move beyond the legacy
functionality, and do new stuff. Personally I find the optional
buttons a waste of space and I'd like to get rid of them, so that the
space can be used for more useful things.
Search Bar
---------------
VisualWorks and Dolphin both have areas where you can type a class
name or selector and have the browser find it for you. It's really
handy, we should have this in OB as well.
Multiple Selection in Columns
----------------------------------------
This would allow commands to be applied to more than one node at a
time, which would be very handy.
Tabs in the Text Panel
------------------------------
This is another handy feature of VW - the ability to look at
different representations of a method - source code, byte code,
version history etc.
Window Reduction
--------------------------
OmniBrowser has some features to reduce the number of windows that
get opened during normal development, but I still end up with lots
and lots of windows that aren't in use. I'd like to experiment with
different approaches to keep the number of stale windows to a minimum.
This is enough work to keep me occupied for quite a while, but if
anyone has other ideas or feature requests, I'd like to hear them. In
particular, I'm wondering what to do about Actions. Should I leave
the actions infrastructure in place so as not to break existing
browsers? Should it be deprecated? Should we just migrate everything
to commands and ditch actions?
Colin
More information about the Setools
mailing list