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 <[email protected]> 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 >
_______________________________________________ General mailing list [email protected] http://livelykernel.sunlabs.com/mailman/listinfo/general
