Hi,
On Jan 17, 2016, at 7:56 PM, Nicolai Hess
<nicolaihess(a)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."