[squeak-dev] Changes to Browser building/opening

David T. Lewis lewis at mail.msen.com
Sat Oct 21 17:35:12 UTC 2017

On Fri, Oct 20, 2017 at 05:04:06PM -0700, tim Rowledge wrote:
> I hurt my back a couple of weeks ago and so I found myself forced to sit on my office chair as the least painful place to be. With nothing urgent to do other than avoid boredom, I finally thought to myself that I would attack an annoyance that has been annoying me for years in Squeak.
> Well as is so often the case, as I dug into what to do I got distracted. In this case I stumbled upon the assorted Browser related methods for building the browsers.  So far as I can see waaaay back when we adopted the ToolBuilder idea a whole bunch of methods got hacked about to work with it and then just left to moulder. For example a number of messages that clearly used to actually build windows got turned into code that did no such thing and instead assembled a spec to pass to a toolbuilder. The comments usually didn???t even get updated. Oh, and the ability to spawn browsers with a partially edited bit of code seems to have gone away at that point. And the simple toolbuilder idiom that allows 
>   ToolBuilder open: BlahClass
> didn???t seem to work too well froBrowsers either. Part of that is because the Browser code can build a stack of different UIs instead of the simplistic approach of 'one class one UI???. We could have split Browser up a bit to make that work, and maybe we still should. It has appeal.
> There was much related ???fun??? whilst digging into the area, where I discovered that we have SystemNavigation having some code that tries to build assorted browsers (with many comments containing broken examples, sigh), ToolSet and StandardToolSet gathering some Browser building and SystemBrowser doing nothing more complex than deciding between Browser and PackagePaneBrowser. None of this has much in the way of helpful commentary. Oh and let???s not forget UIManager which seems to get tangled in it as well. I found places where a browser was referred to both via ToolSet and Browser. And whilst having pragmas to mark menu related methods is a neat idea it would be a whole lot better if only you could sensibly find the damned things with implementors-of etc. 
> I made a small pile of changes to clean up at least some of this. I???ve made the building more explicit and enabled 'ToolBuilder open: Browser/HierarchyBrowser/ClassListBrowser' etc. I managed to make the spawning-with-partial-text thing work in all the cases I can find. I think I broke something in MVC projects but right now I can???t even get into an mvc project to look - and given that I didn???t (knowingly) touch changesorters I???m not sure it???s my fault.
> The changes range across several MC packages so I think it is better to share the changes file for an initial look-see. It???s on the swiki at http://wiki.squeak.org/squeak/2736

Following an initial look at the change set, I would say that the changes
for System (comment fixes) should go directly to trunk, and the changes for
Tools seem to stand on their own, so I think you can post them to the inbox.

My working image has your change set loaded, then I backed out everything
except the Tools changes, and all still seems to be fine. That's why I think
it should be OK to post the Tools update to the inbox.

I would vote for the Tools changes to go from inbox to trunk, but it would
be best if one or two other people can look at them first.


More information about the Squeak-dev mailing list