Check out RealEstateAgent. System tries to decided how big default windows
should be based on staggering policy (from prefs) and size of display. The
buttons resize dynamically in part to accommodate this (I think.) On my
little display, The system browser opens to small that it's unusable. I have
a one line "fix" for this in the inbox, but it looks like no one has (or
perhaps will) apply it. The deal is, if a default window height is less that
300, it's useless on my box, so I added a check that sets it to 300 hundred
at minimum.

FWIW, I hate that the buttons resize, RealEstateAgent is weird, and I can't
wait to dig in an rewrite some of this junk. At this point though, my guess
is that this stuff will have to wait for 4.2.

On Fri, Apr 2, 2010 at 2:02 PM, Ken Causey <ken at kencausey.com> 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.
>
> Ken
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100402/61b4e9ea/attachment.htm