Extending OB metagraphs
Colin Putney
cputney at wiresong.ca
Mon May 7 22:22:34 UTC 2007
On May 7, 2007, at 6:15 AM, David Röthlisberger wrote:
> I dream of having a framework which allows me to put different
> browser elements together in any possible combination. For
> instance, I would like to be able to add a column on the left side
> of the definition panel, or I would like to have multiple
> definition panels to provide multiple selection for methods or
> classes. Or then I want to have a column which includes two "sub-
> columns".
>
> While it is possible to implement these kind of things with OB, it
> requires me to "hack" around deep in the framework to actually
> realize such things. Because OB is quite restricted, for instance
> there is always this left to right navigation approach for the
> columns, providing another navigation approach than that is almost
> impossible. But doing so nevertheless leads to a completely
> separated branch of OB which probably can never be merged back to
> the original OB.
>
> My question now is if i am better off implementing my own framework
> to do these kind of things, or if it is worthwhile to think about
> possible solutions to make OB so flexible and generic that even
> these "special" things can be achieved without having two
> completely separated branches of OB?
> I would personally prefer to have only one branch of OB, or maybe
> another branch being only slightly different, but I would be very
> interested to see what others think?
>
> I believe OB is really great in implementing that kind of browsers
> that exist right now in Squeak, strictly following the navigating
> and browsing pattern typically to Squeak. But when it comes to
> experiment with some other approaches to navigate, browse and
> maintain source artifacts then OB is probably too restricted right
> now. So I am wondering if there is a motiviation to make the OB
> framework even more flexible to be able to use it also for
> experimental browsers following new concepts of browsing, or if OB
> should "just" be and remain a better framework to implement
> standard browsers in Squeak?
Hi David,
That's another hard problem. ;-)
I think that OmniBrowser is moving in this direction. As we use it
for more and more different types of browsers, the framework is
evolving, and becoming simpler and more flexible. There is certainly
a tension between flexibility and simplicity/efficiency/
effectiveness, and I don't want to make OB so general as to be
nothing more than a widget library. Still OB could stand to be a lot
more flexible, and I'm sure it would benefit from being stretched to
accommodate your "special" browsers.
One thing that will help is the recent shift to using OBBuilder
subclasses to create visual elements of the UI. Right now it uses a
fairly simple layout scheme, but that could be extended to handle
more complex layouts. Also, I think most of the things you mention
above could be accomplished by creating new types of panels. I'm
currently involved in a rather hairy refactoring of the very core of
OB, to reduce the coupling between OBColumn and it's collaborators,
and this will allow columns to be composed differently from the
current left-to-right convention.
Tell me, are you using the latest versions of OB from http://
source.wiresong.ca? These version are much more flexible than earlier
releases, such as what's on SqueakMap or included in 3.9. Once the
core refactorings are finished, I'll be taking stock of what needs to
be done for a 2.0 release, so the "latest and greatest" OB browsers
can be put into wider use.
Colin
More information about the Squeak-dev
mailing list
|