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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Dan Ingalls-5
> 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


Reply | Threaded
Open this post in threaded view
|

[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@7:01 PM, Daniel Ingalls <[hidden email]> 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@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