Mats Nygren <nygren at sics.se> wrote:

> 2) 
>  i) click on the 'keep this menu up item' (it happens to exist on this
> menu, on menus without this I dont know how to get a halo for a menu
> item)
>  ii) halo click on 'jump to project'
>  iii) halo click again, it isnt crystal clear visually that it is the
> correct menu item, but assume that
>  iv) click one the tool that is described as 'debug'
>  v) click on 'inspect morph'
>  vi) a small window entitled MenuItem appears
> [vii) clicking on 'contents' show that this is indeed 'jump to project']
>  vii) clicking on 'selector' shows #jumpToProject
>  viii) clicking on jumpToProject twice, type alt-m and a larger window
> appears with five lines
>  lets says we are now at an equivalent place as in version 1) above
> 
> I cannot agree that 2) is " a way to do this right" and 1) is not. (I am
> not defending my actual coding, its quite likely quite bad in many
> respects)
> 
> </argumentative>

[...]

> > So how about adding the option to a
> > red halo?  It would still be pretty fast, and it should be much easier
> > to find.  
> 
> much easier?
> 


<argumentative>
Yes, much easier.  If you aren't using halos, you aren't using morphic
the way a programmer should.  If you are using halos, then you can
figure this out very quickly.

And if you don't use inspectors and alt-m, then you again aren't using
squeak the way a programmer should.  There *is* a good bit of very
important knowledge that new Smalltalk programmers seem to miss out on. 
But that's a failure of documentation.  In the Squeak-using class at
Georgia Tech, these things are demonstrated around lab 2, just because
it's so important.

Exploring menus is important, but it can be subsumed under exploring
morphs in general.
</argumentative>


Agreed on the problems of making a transient menu stay up.  There's just
too many kinds of menus in Squeak....


-Lex