a small bridge

Scott Wallace Scott.Wallace at disney.com
Wed May 24 14:21:43 UTC 2000


Using existing tools, an easy way to get quickly to the code that 
implements any menu item or button is to do a "method strings with 
it" query on the wording of the item that interests you.   (This 
query is available on the "more", or "shifted", side of any 
text-editor menu, and you can use cmd-shift-E as a short-cut.)

For example, suppose that, having seen the "definition for..." item 
in the Help menu, you wondered how it was implemented.  You could 
very quickly get to it by going to a workspace, typing "definition 
for...", and hitting cmd-shift-E.

This will give you a message list showing the two methods in the 
system that contain the string literal 'definition for...'.

Looking at either method, you'll immediately find that the associated 
functionality is in a method called #lookUpDefinition.  Double-click 
on "lookUpDefinition" and hit cmd-m, and the resulting 
implementors-browser takes you right to the gold.

Having higher-level tools that suggest and invite and streamline this 
kind of enquiry would make standard techniques such as this 
accessible to more users.

   -- Scott


At 11:32 AM -0700 5/24/00, Mats Nygren wrote:
>"Lex Spoon" <lex at cc.gatech.edu> wrote:
>
>>  ..
>>  Great idea!  I've quite frequently wondered just how a particular menu
>>  item worked.
>
>Thanks!
>
>>   This solution works, but the functionality can be made
>>  easier to find.
>
>As for the details of how to get it, I want it to be just one click, or
>one keypress away. If it is also at other places, as in a halo menu,
>thats fine, but there are many keys and many clicks (24[16] = Powerset
>{shift, ctrl, alt} times { left, [middle,] right }) available. I see no
>reason for not using one of them.
>
>>
>>  First, there's actually a way to do this right now.  In fact, I feel
>>  dumb for not having thought to do this before.  All you have to do is
>>  "inspect morph" on the particular menu item, find the selector instance
>>  variable, and do alt-m.  This is a straightforward use of Squeak's
>>  tools, and I would think any programmer will be able to do this fairly
>>  easily once they've been shown the idea.
>
><argumentative>
>
>Try the following:
>
>"I want to know how 'jump to project' works?"
>
>1) shift-click on it
>
>You get:
>   PasteUpMorph>>jumpToProject
>	Project jumpToProject
>and you are within reach of many related things (knowing about alt-b,
>alt-m)
>
>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>
>
>  >
>  > But looking for a menu item's code should be a common way to explore the
>  > system, so it should be made more accessible.  Shift-clicking is fast,
>>  but it's hard to find out about it.
>
>One has to be told this, that it exist and that it is useful for
>newbie's. The idea started to grow on me while using
>'definition for...' in the help menu. I simply wanted to know where
>the dictionary was located, finding this was simply beyond me. Method 2
>above assumes a lot of knowledge about Squeak. Now I could do:
>  i) shift-click in menu item,
>  ii) click twice on WordNet, alt-b
>  iii) click on [?], and:
>
>Query the WordNet lexicon at Princeton Univ.  At
>http://www.cogsci.princeton.edu/cgi-bin/webwn/
>
>appears. Aint that great!
>
>>  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?
>
>>  The red halo should be one of the first places a programmer
>  > looks when trying to do something with a morph--and a menu item is just
>>  another morph, after all!
>
>I agree. But not everything can be halo-clicked, for example how do
>you get a halo on the HandMorph? How get a halo on a halo-button?
>
>And a thing related to menu-items, one can have a command-key that means
>get to the code
>implementing the following command. For example alt-<something> alt-m
>would get to the same code
>as shift-click 'implementers of it..'. As it turns out this isnt helpful
>(try it), more work is needed here.
>
>>
>>  By the way, I totally agree on putting bridges between the UI and the
>>  underlying code.  It should be entirely possible to build a computer
>>  system that is good for end users and yet is still powerful for
>>  programmers.  Squeak seems to be driving in such a direction.
>
>One of the main reasons for my interest in squeak. And there is
>interesting work to be done.
>I think squeak will continue to excell with time, certain things just
>will never happen if important key information is not within reach. I
>know of no project that is even within reach of Squeak when it comes to
>this aspect.
>
>"The sun never sets in the Kingdom of Squeak"
>
>/Mats Nygren
>>
>>
>>  -Lex





More information about the Squeak-dev mailing list