On Fri, 24 Mar 2000, Vassili Bykov wrote:

> Here is an implementation of what was discussed but not done at SqueakEnd on
> Sunday morning: Layouts (an analog of VW's LayoutFrames) and a few base
> methods fixed to make use of them.  They make buttons and some other UI
> elements of standard browsers and the debugger fixed size.
>
> The changes are relative to 2.7 image.

Vassili, thanks for the changeset.  The inability to create fixed-height
subpanes in SystemWindows has been a long annoyance for me.

(e.g. The instance/?/class buttons on the Browser needlessly adjust their
heights when the window is resized... especially annoying if you size the
window smaller and then the text in the buttons is obscured.  Same goes
for the optionalButtons panes, annotation panes, category panes in
hierarchy browsers, etc.)

I would like to see this functionality included in the base image at some
point.  Your implementation seems reasonable to me... it still leaves room
for defining subpanes the old way.

I did notice a minor bug, though.  After loading the changeset and opening
a System Browser, I noticed that fairly often (maybe 50% of the time), the
black borders around the window and between the subpanes are 3 pixels
thick, instead of 2 pixels thick.  I'm guessing this is some kind of
rounding error... it even occurs with windows such as the Method Finder,
which don't have any fixed-size subpanes.

Oh wait, I was just testing with 2.8alpha.  Things look better (mostly)
with 2.7.  Sorry.

Anyway, I thought I'd also mention a couple of sort-of-related wish list
items...

1. It would be nice to have a simple single-line pluggable text morph
which is not scrollable, when a fixed-height (single-line) subpane is
desired. This could be used for annotation panes, category panes in
hierarchy browsers, the template ("*") pane in the file list window, the
text entry pane in the method finder, etc., etc.  Scrollbars serve no
purpose in these text panes, and they usually look clunky (especially
inboard) because they stretch down below the lower border of the pane, and
can interfere with resizing the lower border (a bug).

This probably wouldn't be too hard to implement... I guess one could add a
little functionality to PluggableTextMorph (or maybe just TextMorph?) to
make it non-scrollable, prevent wrapping, etc.

2. Another nice thing would be the ability to drag all associated
fixed-sized panes when resizing a pane border.  For example, dragging the
horizontal border above the method text pane in the System Browser would
also drag the instance/class buttons up and down with it, since they are
of "fixed" height anyway.  This capability would be a thing of wondrous
beauty... although there would be some complications.  You would probably
need to prevent resizing of the fixed-size panes in general for this to
work.  (Otherwise, e.g. if you had both an annotation pane and the
optionalButton pane open, there would be confusion over what to resize
versus what to move.)  Arguably, you don't really need to be able to
resize these fixed-size panes anyway, though.

Implementing this would not be as difficult as it sounds... I think the
only changes would be in SystemWindow.  (To see if a subpane is of fixed
height, you'd simply test for topFraction = bottomFraction...)  I may try
coding this.

Of course, you could also take a completely different approach to
fixed-size subpanes, by having the SystemWindow not register them as an
official subpane (paneRect).  Instead, you'd simply implement them as a
submorph within an existing subpane.  It would then be visually obvious
that they were not resizable, too.  (I guess this would only work for
Morphic.)

Anyway, enough rambling for now...

- Doug Way
  EAI/Transom Technologies, Ann Arbor, MI
  http://www.transom.com
  dway at mat.net, @eai.com