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

> 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.

> 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@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
>