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