UI Buttons (was Re: [squeak-dev] MessageNames: clicking on class
frank.shearar at angband.za.org
Sat Apr 3 06:38:43 UTC 2010
Ken Causey wrote:
> On Fri, 2010-04-02 at 18:38 +0200, Frank Shearar wrote:
>> Ken Causey 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.
>> Ah, now that I play around with the Browser, I see what you mean. The
>> behaviour is... not ideal.
>> I'd like to see the instance/?/class buttons resize like the
>> browse/send/implementor/etc buttons: constant size up until a point, and
>> then decreasing proportional to their containing panel.
>> I think you'd get this by putting both the instance/?/class buttons'
>> PluggablePanel and the class list's PluggableListMorphPlus inside a
>> common parent PluggablePanel.
>> I'll try play around with it tonight and see what I can do. (Given that
>> my total ToolBuilder experience is the hour I spent on
>> Tools-fbs.(220|221).mcz, I look forward to gentle pointers on how to not
>> make a hash of things!)
> Thanks Frank,
> I'm puzzled. What is the use case for having the buttons resized? It
> seems to me that a button has a desirable size and you make it that size
> and leave it.
> I appreciate your looking into this.
I agree, Ken. That'd be my first prize. But as a less ambitious goal I
just want all the buttons to work in the same way.
But I think what I was TRYING to say was what you were describing.
Playing around some more this evening, I found the main annoyance was
not resizing the Browser (the basis of my want-to-have description
above) but when moving the divider between the lists and the code pane.
That's when the makes-Ken-sad behaviour really kicks in.
I did try play around with Browser this evening (see my other mail), and
realised that I need to read a lot more ToolBuilder code before I can
properly address the issue. Which is fine: I find debugging a great tool
for learning a codebase.
More information about the Squeak-dev