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