> On 2020-10-17, at 1:37 PM, tim Rowledge <tim at rowledge.org> wrote:
> 
> What struck me though was how unhelpful the browser ends up being in this case. What we get is a long list of methods where
> a) there are duplicates - see MenuMorph>>#setTitleParametersFor: for an example. It apparently sends titleColor, titleBorderStyle, titleBorderColor and titleBorderWidth and appears 4 time in the browser. I'd claim that it would be far better to build some variety of Set of MethodReferences in MessageSet>>#initializeMessageList:

Making a Set instead is easy enough, and then if we convert that to a SortedCollection we get a more useful result. It only takes trivial changes to two methods to do this.

Unfortunately it also reveals that the SystemNavigation>>#browseMessageList:name:autoSelect: is in need of some improvement since the 'nothing selected' label is set to the proffered label + the raw incoming collection size - and that is not correct after the Set conversion. 

This raises a philosophical question about how we really want MessageSet browsers to behave. If we create a list with one method reference repeated 100 times, is there any reason at all anyone would want to see a 100 entry browser list? And is there any reason anyone can think of to not move that label-futzing code into the actual tool instead of a rather unwarranted assumption in the SystemNavigation code?

There a promising (if complicated) method #adjustWindowTitleAfterFiltering but unfortunately there is no containing window at the relevant time and so it cannot do the job.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: IBLU: Ignore Basic Laws of Universe