So I have some fixes to some of the defects mentioned here. How could mere 
mortals get permission to update Squeak 3.9 code? I was told a while back:

As soon as source.squeakfoundation.org
<http://source.squeakfoundation.org/>is up again, you directly
commit into the inbox there. I then will merge this into the 3.9
repository quite fast.
 
I created an account on
source.squeakfoundation.org<http://source.squeakfoundation.org>(initials
jrp) and am ready to proceed. Would this be just a basic
Monticello check-in to submit some fixes?

Regards,

John

On 9/13/05, Jesse Welton <jwelton at pacific.mps.ohio-state.edu> wrote:
> 
> 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
> 
> 


-- 
It's easy to have a complicated idea. It's very very hard to have a simple 
idea. -- Carver Mead
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20050913/d9b32744/attachment.htm