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

[Philip Weaver]

I do like buttons over select all, alt-d! :-) I was thinking about that some
- but I decided that I'm just going to work with customizing the existing
MenuMorph to start since it's already there. I did rewrite the main
subMenuItems method and broke it down into smaller classes in:
lively.menus.xxxxx. I did this to make it easier to tweak those menu
actions via the code browser and to add my own submenus. I hope to ask for
input/acceptance etc.
Dan, I don't understand the reference to "unified" below. Are you basically
referring to sharable actions? I am a super fan of the Actions API from
Swing.

Phil

On Tue, Feb 24, 2009 at 7:01 PM, Daniel Ingalls <Dan.Ingalls at sun.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://livelykernel.sunlabs.com/pipermail/general/attachments/20090224/e3e23f6f/attachment.html