Oh yes, I agree about the button panes.  I keep them all turned off as
much as possible, and would like to add a preference to disable the
ones in the debugger altogether.

The main problem with buttons as a UI-element is that they provide
little or no output.  Instead, they just sit there, taking up valuable
screen space, waiting for one single type of gesture of input, a
left-cick.  I believe this is mostly to accomodate users who do not
have Basic Computer Literacy, the same kind of users who will not go
very far with Squeak anyway.

Not a bargain...



On Thu, Apr 1, 2010 at 1:59 PM, Ken Causey <ken at kencausey.com> wrote:
> On Thu, 2010-04-01 at 13:20 -0600, Chris Muller wrote:
>> > I noticed that the new search morph in the docking bar will bring up class
>> > names as well as selector names. For instance, searching for "obj" will show
>> > things like "AbstractObjectsAsMethod".
>> >
>> > If you hit the browse button on these entries, though, nothing happens.
>>
>> This is because the preference, #alternativeBrowseIt is disabled, by
>> default.  Crazy isn't it?  If just enable that and you can (b)rowse
>> hierarchy's, i(m)plementors, or se(n)ders with those keys..
>>
>>  - Chris
>
> It's not that simple.  There is another clearly related problem that
> this does not address (oh, and your solution does not fix the problem,
> it simply leaves out the most glaring instance of the problem).  The
> 'instance', '?', 'class' buttons have the same problem as the alternate
> browser buttons.  Even more fun because they are in a subpane of the
> upper frame, try to enlarge just the source code pane by pulling the
> main divider up...the instance/?/class button pane is squashed and once
> it reaches it's lower limit you can't move the main divider up any
> farther.  Instead you have to start by dragging up the divider between
> the pane listing the classes and the button pane then drag up the
> overall divider leaving enough space for the buttons.  Not intuitive in
> my book.
>
> Ken
>