Hi, > On Jan 17, 2016, at 7:56 PM, Nicolai Hess <nicolaih...@gmail.com> wrote: > > > […]
> > - I really miss the "List Methods using 'varname'/List Methods storing into > > ‘varname' > > Please open an issue for this. > > This issue is one year old: > 14583 inspector and instvars : list methods storing into/using > Ok. Thanks. Fixed. > […] > > (since when do we put buttons in the title pane? > > Since Glamour makes it easy to have them there :). The GTPlayground and > GTInspector have them, too. > > still I don't think this is a good idea. What is the difference between > action buttons in the title pane > and the other one. We have now moved the accept and cancel to the contextual menu for now. However, the longer term goal is to change this pattern. Here is a longer explanation. We think of the IDE like terms an object-oriented system built using a language. From this point of view, an action is put in the context that provides enough information to trigger it. So, for actions that do not rely on the selection, or on the cursor position, we can safely put them in the toolbar of the presentation. For global actions (like refreshing the whole inspector), we put them all the way in the title bar. For example: - "Do It” depends on the selection or cursor, and thus it is added to the context menu - “Accept" is not specific to the current location of the cursor or of the selection and can be made presentation specific (added to the toolbar of the presentation). - Switching the whole debugger to a “Bytecode” one is global for the whole debugger, and it is added to the top of the visual hierarchy. This choice also documents the scope of an action. For example, imagine having a global toolbar with actions that only do something in a certain pane (out of possible many). How will you know before triggering what is the effect going to be? But, if you always put the action to the scope that it affects, there is a more clear connection because cause and effect. And there is yet another advantage. When you stick with this design, you get potentially reusable components. This does require some getting used to. And this design will not necessarily work for general UIs. But, an IDE is not a general UI. It is made for programmers, and in our case, it is made for object-oriented programmers, and we can use the abilities of such programmers in our designs. Does this explanation make more sense? Cheers, Doru -- www.tudorgirba.com www.feenk.com "To utilize feedback, you first have to acquire it."
