Extending OB metagraphs

> On May 5, 2007, at 11:07 AM, Damien Cassou wrote:
>
>
>> Is it clearer now ? The package DynamicProtocols has to modify the
>> meta graph. I can do it when the meta graph is constructed in
>> OBCodeBrowser>>addTo* but this would be an override. My current
>> solution is to reimplement #addTo: in the subclasses I want:
>> OBSystemBrowser and OBHierarchyBrowser.
>>
>
> Yes, this is hard.
>
> A lot of my recent work with OB has been aimed at improving the
> extensibility of browsers built with OB. Commands, for example, are
> better than Actions were, mainly because new ones can be added without
> changing any existing code. It's not hard, because code for building a
> list can be extended just by building another list and concatenating
> them.
>
> On the other hand, I haven't had any ideas about making the
> construction of the metagraph extensible. The original idea with OB
> was to have a registry of metagraphs that could be modified in place,
> kind of like the SystemDictionary. If you modified the metagraph, the
> behavior of browsers would change. That turned out to be tricky to
> manage, so we moved to a system where each different type of browser
> has it's own subclass, and builds the metagraph when the browser is
> opened. That's been better, but it doesn't get around the deeper
> problem of extensible graph construction.
>
> 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.
>
> Ideas? Perhaps this is a well-understood problem, and I'm just
> ignorant of the solution.
>
> Colin
>
>

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

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

> Firstly, I think OB needs a graph entity This graph would let methods
> access any node using its name with just a simple call
> (OBGraph>>getNodeNamed:). It should be possible to remove edges too I
> think.
>
> Then, OB has to make this variable directly accessible to all class
> side methods. The graph might be stored in a class variable.
>
> When a new browser is created, all methods whose name starts with
> #buildGraph are executed. Those methods have access to the graph and
> to all its nodes. So, I think they can do whatever they want with the
> graph.
>
> Isn't that enough to have a dynamic graph?
>

> Seems to me that extending browsers by adding commands (such as  
> "find Trait" in addition to "find class") and "fake" elements like  
> DynamicCategories provide, can be done by having registries for  
> them like the Services framework provides for dynamic menus and  
> Browsers (don't know if Services can be reused, or we need to apply  
> some of the same patterns again).
>
> Then the standard browsers can simply add all the relevant extras  
> dynamically, and maybe allow a user to hide some of them.
>
> This dodges the more general question of making the actual graphs  
> extensible. I had an idea about this involving graph rewrite rules,  
> but the solution above sounds simpler, and might work (at least for  
> the current cases), so...

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

>
> On May 5, 2007, at 3:15 PM, Damien Cassou wrote:
>
>
>> Firstly, I think OB needs a graph entity This graph would let methods
>> access any node using its name with just a simple call
>> (OBGraph>>getNodeNamed:). It should be possible to remove edges too I
>> think.
>>
>> Then, OB has to make this variable directly accessible to all class
>> side methods. The graph might be stored in a class variable.
>>
>> When a new browser is created, all methods whose name starts with
>> #buildGraph are executed. Those methods have access to the graph and
>> to all its nodes. So, I think they can do whatever they want with the
>> graph.
>>
>> Isn't that enough to have a dynamic graph?
>>
>
> I suppose it's better than what we have now, but only a little, I
> think. The main problem would be one of ordering and composition. If
> you're doing something like adding dynamic protocols to the graph, the
> code to do that has to run after the main graph has been built, and
> before  code that does other things to existing edges and nodes. There
> would have to be a fairly complex, protocol for orchestrating all of
> that, and even then, I think it would be brittle.
>
> Colin
>
>

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