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!)
frank
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.
frank