LookEnhancements comments

Jesse Welton jwelton at pacific.mps.ohio-state.edu
Tue Sep 13 20:19:46 UTC 2005


I finally got around to grabbing the latest 3.9 and examining the look
enhancements.  Some things are very nice; others are... not.  I'll try
to be constructive and confine my comments as much as possible to
technical details rather than merely complaining about aspects of the
look I don't like.

The new spliter behavior for resizing winow panes is particularly
wonderful.  In particular, I like that the grabbable area is
independent of where the cursor enters.  No more accidentally grabbing
the window because you slide the cursor out of the reframe handle,
along the edge of the frame.  I would very much like to see similar
behavior for the outer edges when resizeOnAllSides is set.  Actually,
the old-style reframe behavior for the outer border is worse now than
it was before.  When moving the mouse from the inside to the outside,
the reframe handle isn't spawned until the hand leaves the window,
where it used to be spawned when leaving a pane.  This means over the
entire distance from the outside of the pane to the outside of the
window, clicks will result in grabbing the window rather than
resizing.  This could happen before, but it required sliding along the
edge of the window to get out of the handle.  It's now a much more
noticeable problem.

There is a bug with both showSplitterHandles and fastSplitterResize
on, where dragging any part of the splitter other than the handle
still resizes the pane, but doesn't give any feedback.

Turning off alternateWindowLook results in black windows with
unreadable titles.  Either the non-alternateWindowLook behavior should
be preserved, or if it is going to be completely unusable anyway, it
should be removed.

Dropping the divider line between browsers' button areas and the
adjoining scroll panes looks weird to me.  It seems particularly weird
when you can still grab the invisible border and resize the button
areas.  A line here to visibly separate them would be good (not sure
what the best way to accomplish that is; I remember it being awkward
way back when I last messed with window layout), and I'd be inclined
to drop the resizing in this particular case.

Personally, I find the gradient colors of the windows awful, and I was
quite disappointed to find that they're hard-coded, with no preference
to turn them off.  A preference here would be great, along with a way
to enable something like the old titlebar decorations.  (Despite the
gradients, the new title bars look really plain to me.  Menus are
better-decorated.)

Menu borders are also hard-coded, overriding any preference settings
for width or color even for classic non-3d menus.  The inset border of
the menu title area is lost, but ought to be preserved for
menuAppearance3d.

Since I've been using the 3d appearance with menu icons off, the move
to a hard one-pixel border makes the menus appear cramped, especially
when all the window borders have increased in width.  Increasing the
layoutInset from 3 to 4 helps a lot.

MenuMorph class>>initialize sets a few preferences that differ from
the settings in Preferences class>>restoreDefaultMenuParameters.
Surely it would be better to set these values in the latter place?
It's also a problem that setting menuTitleBorderWidth to 1 (as the
latter method does) results in only the inner part of the label area
being inset.  Maybe this is the reason the inset label area was
dropped?  I'd rather see the whole label area inset.

-Jesse



More information about the Squeak-dev mailing list