[squeak-dev] Changes to Browser building/opening

Kjell Godo squeaklist at gmail.com
Tue Oct 24 22:20:40 UTC 2017

On Fri, Oct 20, 2017 at 17:04 tim Rowledge <tim at rowledge.org> 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

i have Methods which have case statements in them which switch off of the
Method inputs which act like command line options. so there might be seven
different options and seven different cases. do you think that these cases
should be separated out into seperate Methods( equal selector prefixes )
one for each of the cases?

i sometimes feel that if the cases are all similar then it is easier to see
the similarity if you can just scroll text up and down.  so just use a case
statement.  but it does get more messy upon first glances. but separating
them out into seperate Methods is more to the standard.

But in Dolphin i also have a Tree browser which allows traversing the
seperate Window tree bullets keyboard only which can have the same effect
as scrolling text so. because you can set up each Window seperately once
and it will remember it. but with the SystemBrowser i have to scroll the
text of each Method i come to to get to the code and by then i lose track.
i suppose i could make a tree file which has these seven Methods in it and
i could then get the same eye ball effect as scrolling text. i should try
it. or i could get rid of the initial comments at the top of each Method
which are according to a repeated template. yes i should probably do this.
that way i would not have to scroll text as much and then the SystemBrowser
might be good enough more.

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
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> It said, "Insert disk #3," but only two will fit!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20171024/b7df1025/attachment.html>

More information about the Squeak-dev mailing list