I have the impression that indeed having a model of components for  
Browsers would be really great.
Having the possibility to have whiskers multiple panes or different  
flow of interaction is important.

May be you need to have flow element taking and input displaying  
something and propagating events to listeners. May be implementing a  
small case study can help you what you need.

BTW I would love to get your OB package integration extensions :)

Stef

On 7 mai 07, at 15:15, David Röthlisberger wrote:

>
>> So, here's the problem. Perhaps someone here has an insight that  
>> can help solve it. (For more detail, read the OB paper that was  
>> recently announced here.)
>> The behavior of each browser is governed by a metagraph. A  
>> metagraph is a DG, consisting of nodes connected by directed  
>> edges. The graph can have cycles, and they frequently do. Both  
>> nodes and edges can have additional attributes attached to them.  
>> We need to be able to programmatically build a metagraph in such a  
>> way that the code used to build it can be dynamically discovered,  
>> can reside in several different packages, can affect the structure  
>> of the graph without overriding code in another package, and be  
>> composed without risk of creating invalid graphs.
>
> I don't have a clever solution for that problem, unfortunately, but  
> I would like to mention another problem with OB that is troubling  
> me a bit.
>
> 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?
>
> Thanks for any comments on this.
>
> Kind regards,
> David
>
>
>