[General] Feedback: Exposing the Individual Popup Menu Functions for Code Browser

[Daniel Ingalls]

> I'm beginning to tinker with editing system code via the code  
> browser. In my view, as a new user, some of the best candidates for  
> tweaking are the actions in the popup menu: create rectangle but  
> instead green, create text morph but instead with stickies colors,  
> open code browser with larger bounds. However none of these actions  
> are exposed to the code browser individually - you instead have to  
> edit the entire method: subMenuItems. So it would be nice if this  
> method was instead a new set of classes (perhaps grouped in a  
> namespace for grouping in the code browser). The subMenuItems method  
> even has an existing comment: // FIXME this boilerplate code should  
> be abstracted somehow.
>
> I think this is very important for new users to quickly understand  
> using the code browser. Perhaps I will refactor that method over the  
> next few days - but if anyone runs with this this let me know.

Hi, Phil -

I agree that this needs to be cleaned up.  Since it's under  
discussion, there are a number of things to be unified around menus,  
buttons, and actions:

* Menus should be able to be "nailed" -- ie remain on screen like a  
set of buttons

* Menu items should be able to be torn off and function as a buttons,  
and buttons should be able to be dropped into menus.

* Menu items/buttons should be able to be "inspected" to reveal the  
code for their action and also help regarding what they do (of course  
these are the same if the code is well written.

* Codewise, actions should be unified using JavaScript functions.  I'm  
guilty of having put in the more verbose form of receiver/messaage/ 
args constructs;  these should be replaced unless we decide they are  
better for some reason.

* While we're at it, SchedulableActions used in the scheduler for  
alarms and repetitive actions should similarly be unified.

* Any Morph should be able to be made into a "button" -- ie, to lose  
its normal mouse response and simply become a button.

* And of course we need to decide how many kinds of buttons we want to  
support -- toggles, act on down, act on up (with roll-out escape), etc.

* The current links in text should also function consistently with  
buttons.

-------------------

Naturally the same kinds of comments refer to other things that can be  
taken apart.  Can you grab a class pane out of the system browser for  
use any time you want to browse that class?  Etc, etc.

This is why it's hard to "finish" a system.

Anyway, thanks for your interest and useful feedback on these topics.   
You will soon be used to how everything works and hence worthless as a  
critic ;-)

	- Dan