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:<br>
<br>
<div style="margin-left: 40px; font-style: italic;">As soon as <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://source.squeakfoundation.org/" target="_blank">source.squeakfoundation.org</a> is up again, you directly
<br>
commit into the inbox there. I then will merge this into the 3.9<br>
repository quite fast.<br>
</div>
<br>
I created an account on <a href="http://source.squeakfoundation.org">source.squeakfoundation.org</a> (initials jrp) and
am ready to proceed. Would this be just a basic Monticello check-in to
submit some fixes?<br>
<br>
Regards,<br>
<br>
John<br>
<br><div><span class="gmail_quote">On 9/13/05, <b class="gmail_sendername">Jesse Welton</b> <<a href="mailto:jwelton@pacific.mps.ohio-state.edu">jwelton@pacific.mps.ohio-state.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I finally got around to grabbing the latest 3.9 and examining the look<br>enhancements. Some things are very nice; others are... not. I'll try<br>to be constructive and confine my comments as much as possible to<br>technical details rather than merely complaining about aspects of the
<br>look I don't like.<br><br>The new spliter behavior for resizing winow panes is particularly<br>wonderful. In particular, I like that the grabbable area is<br>independent of where the cursor enters. No more accidentally grabbing
<br>the window because you slide the cursor out of the reframe handle,<br>along the edge of the frame. I would very much like to see similar<br>behavior for the outer edges when resizeOnAllSides is set. Actually,<br>the old-style reframe behavior for the outer border is worse now than
<br>it was before. When moving the mouse from the inside to the outside,<br>the reframe handle isn't spawned until the hand leaves the window,<br>where it used to be spawned when leaving a pane. This means over the<br>entire distance from the outside of the pane to the outside of the
<br>window, clicks will result in grabbing the window rather than<br>resizing. This could happen before, but it required sliding along the<br>edge of the window to get out of the handle. It's now a much more<br>noticeable problem.
<br><br>There is a bug with both showSplitterHandles and fastSplitterResize<br>on, where dragging any part of the splitter other than the handle<br>still resizes the pane, but doesn't give any feedback.<br><br>Turning off alternateWindowLook results in black windows with
<br>unreadable titles. Either the non-alternateWindowLook behavior should<br>be preserved, or if it is going to be completely unusable anyway, it<br>should be removed.<br><br>Dropping the divider line between browsers' button areas and the
<br>adjoining scroll panes looks weird to me. It seems particularly weird<br>when you can still grab the invisible border and resize the button<br>areas. A line here to visibly separate them would be good (not sure<br>what the best way to accomplish that is; I remember it being awkward
<br>way back when I last messed with window layout), and I'd be inclined<br>to drop the resizing in this particular case.<br><br>Personally, I find the gradient colors of the windows awful, and I was<br>quite disappointed to find that they're hard-coded, with no preference
<br>to turn them off. A preference here would be great, along with a way<br>to enable something like the old titlebar decorations. (Despite the<br>gradients, the new title bars look really plain to me. Menus are<br>better-decorated.)
<br><br>Menu borders are also hard-coded, overriding any preference settings<br>for width or color even for classic non-3d menus. The inset border of<br>the menu title area is lost, but ought to be preserved for<br>menuAppearance3d.
<br><br>Since I've been using the 3d appearance with menu icons off, the move<br>to a hard one-pixel border makes the menus appear cramped, especially<br>when all the window borders have increased in width. Increasing the
<br>layoutInset from 3 to 4 helps a lot.<br><br>MenuMorph class>>initialize sets a few preferences that differ from<br>the settings in Preferences class>>restoreDefaultMenuParameters.<br>Surely it would be better to set these values in the latter place?
<br>It's also a problem that setting menuTitleBorderWidth to 1 (as the<br>latter method does) results in only the inner part of the label area<br>being inset. Maybe this is the reason the inset label area was<br>dropped? I'd rather see the whole label area inset.
<br><br>-Jesse<br><br></blockquote></div><br><br clear="all"><br>-- <br>It's easy to have a complicated idea. It's very very hard to have a simple idea. -- Carver Mead