cool to hear about that.
This is a pity thatthere is not enough doc on reflective application  
builder that were built around 1995 at the VUB but I saw demoes and  
this was cool (kind of plug and play of browser elements).

Stef

On 8 mai 07, at 00:22, Colin Putney wrote:

>
> 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
>