Extending OB metagraphs
stephane ducasse
stephane.ducasse at free.fr
Tue May 8 06:55:33 UTC 2007
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
>
More information about the Squeak-dev
mailing list
|