[Pharo-project] a question about method browsers in pharo
Hi Folks, I am confused by the various method browsers in Pharo. If I <cmd>-m on (say) @ in a Workspace, then I get an "Implementors" view with two panes, the top ones showing 6 implementors of @. If I click on any implementation, I see the source code in the second pane and that's all. Now, If I click on the "implementors" button I get a *new* Implementors browser that looks exactly the same, but isn't. Now if I click on one of the methods, I also get in addition to the source code in the bottom pane, a nice *third* sliding panel on the top with all the messages sent in that method. I can then conveniently browse through the whole call tree. How come I only get the more powerful method browser by explicitly clicking on "implementors" but not when I type <cmd>-m? If I enable halos and explore the morphs, I see that the first one has as its model an OBImplementorsBrowser, and the second an OBMethodListBrowser. Why not simply use the latter? I searched for references to both, but did not immediately see how to change the behaviour on <cmd>-m. - on
Yes it is a bit frustrating. For example the OBdebugger in the dev image does not have all the menu items and the problem is that this is always under stress that we get to notice that :) Stef On Feb 7, 2009, at 12:44 PM, Oscar Nierstrasz wrote:
Hi Folks,
I am confused by the various method browsers in Pharo.
If I <cmd>-m on (say) @ in a Workspace, then I get an "Implementors" view with two panes, the top ones showing 6 implementors of @. If I click on any implementation, I see the source code in the second pane and that's all.
Now, If I click on the "implementors" button I get a *new* Implementors browser that looks exactly the same, but isn't. Now if I click on one of the methods, I also get in addition to the source code in the bottom pane, a nice *third* sliding panel on the top with all the messages sent in that method. I can then conveniently browse through the whole call tree.
How come I only get the more powerful method browser by explicitly clicking on "implementors" but not when I type <cmd>-m?
If I enable halos and explore the morphs, I see that the first one has as its model an OBImplementorsBrowser, and the second an OBMethodListBrowser. Why not simply use the latter? I searched for references to both, but did not immediately see how to change the behaviour on <cmd>-m.
- on
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi Oscar,
If I enable halos and explore the morphs, I see that the first one has as its model an OBImplementorsBrowser, and the second an OBMethodListBrowser. Why not simply use the latter? I searched for references to both, but did not immediately see how to change the behaviour on <cmd>-m.
I think it is the other way around: In the workspace you get the OBMethodListBrowser and in the class browser the OBImplementorsBrowser? The reason for this is that the workspace passes the request to the SystemNavigation class. After this class has gathered the set of messages to display, it passes this set to a method opening the so called message set browser which can only reason about a set of methods, not about whether these are senders or implementors. That's why we get a generic message list browser there but a dedicated implementors browser in OB. So we need to change SystemNavigation to achieve the same result in both scenarios. I can propose a change set. David
I just checked -- you are right, I got it backwards. A change set would be great. Is there a real reason to keep the OBMethodListBrowser? What is it good for? Cheers, - on On Feb 9, 2009, at 16:12, David Röthlisberger wrote:
Hi Oscar,
If I enable halos and explore the morphs, I see that the first one has as its model an OBImplementorsBrowser, and the second an OBMethodListBrowser. Why not simply use the latter? I searched for references to both, but did not immediately see how to change the behaviour on <cmd>-m.
I think it is the other way around: In the workspace you get the OBMethodListBrowser and in the class browser the OBImplementorsBrowser?
The reason for this is that the workspace passes the request to the SystemNavigation class. After this class has gathered the set of messages to display, it passes this set to a method opening the so called message set browser which can only reason about a set of methods, not about whether these are senders or implementors. That's why we get a generic message list browser there but a dedicated implementors browser in OB.
So we need to change SystemNavigation to achieve the same result in both scenarios. I can propose a change set.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
A change set would be great.
ok, what I did is to put new versions of System and Tools into PharoInbox: System-david_roethlisberger.221 Tools-david_roethlisberger.141 I adapted SystemNavigation and ToolSet to be able to distinguish between implementors and senders, so that a concrete ToolSet implementation can open a dedicated browser. I also adapted DEVToolSet which actually opens the correct OB based browser to show senders or implementors. To get this you need to update ImageForDevelopers and OB itself to the latest versions. Would be good if someone could test and harvest these changes.
Is there a real reason to keep the OBMethodListBrowser? What is it good for?
It's used to mimic MessageSet, the traditional browser for senders, implementors, and any other list of messages. I guess this browser makes sense to show unrelated methods, for instance all methods containing a halt, where we don't care about the senders of those messages. David
On Feb 9, 2009, at 16:12, David Röthlisberger wrote:
Hi Oscar,
If I enable halos and explore the morphs, I see that the first one has as its model an OBImplementorsBrowser, and the second an OBMethodListBrowser. Why not simply use the latter? I searched for references to both, but did not immediately see how to change the behaviour on <cmd>-m. I think it is the other way around: In the workspace you get the OBMethodListBrowser and in the class browser the OBImplementorsBrowser?
The reason for this is that the workspace passes the request to the SystemNavigation class. After this class has gathered the set of messages to display, it passes this set to a method opening the so called message set browser which can only reason about a set of methods, not about whether these are senders or implementors. That's why we get a generic message list browser there but a dedicated implementors browser in OB.
So we need to change SystemNavigation to achieve the same result in both scenarios. I can propose a change set.
David
On Wed, Feb 11, 2009 at 2:17 PM, David Röthlisberger <squeak@webcitas.ch> wrote:
To get this you need to update ImageForDevelopers and OB itself to the latest versions. Would be good if someone could test and harvest these changes.
Thank you for updating ImageForDevelopers. I saw you also updated the Squeak branch, is that an error? -- Damien Cassou http://damiencassou.seasidehosting.st
To get this you need to update ImageForDevelopers and OB itself to the latest versions. Would be good if someone could test and harvest these changes.
Thank you for updating ImageForDevelopers. I saw you also updated the Squeak branch, is that an error?
No, I also use this in Squeak. There of course it's difficult to get the System and Tools packages updated... so I do this manually. DEVToolSet still works as usual even if System and Tools don't contain this change, so I was thinking that it doesn't do any harm when the change is also in DEVToolSet for Squeak. David
On Wed, Feb 11, 2009 at 3:29 PM, David Röthlisberger <squeak@webcitas.ch> wrote:
No, I also use this in Squeak. There of course it's difficult to get the System and Tools packages updated... so I do this manually. DEVToolSet still works as usual even if System and Tools don't contain this change, so I was thinking that it doesn't do any harm when the change is also in DEVToolSet for Squeak.
I agree, thank you -- Damien Cassou http://damiencassou.seasidehosting.st
participants (4)
-
Damien Cassou -
David Röthlisberger -
Oscar Nierstrasz -
Stéphane Ducasse