Dan Ingalls wrote:
With sincere appreciation of all the points raised regarding 2.9ff possibilities, we are declaring this to be a fast-track beta for Release 3.0, targeted to freeze (in aobut a week) and ship on the CDROM for Mark and Kim's forthcoming book on Squeak (*). Therefore we will greatly appreciate any and all testing you can give it.
Goodbye 2.9, we hardly knew ye. :)
We plan to issue an image with all these changes, and with a morphic front end (you can still use MVC if desired) in the next day or two.
Hooray! A morphic front end will help with some of the out-of-the-box issues people have with Squeak, IMHO.
I guess there won't be time to stick in a new look & feel for 3.0 after all, if 3.0 is to be the release name for the Squeak book... ah well. I guess it wouldn't make much sense to have a new look in the release for the book, since the pictures in the book will all be based on the old look anyway.
We will limit further updates between now and the CD freeze to bug fixes.
The only small plug I would make would be to include Jesse Welton's LayoutFix changeset posted earlier today, which is sort of a bug fix. (It fixes the problems Whisker has with the current LayoutFrame stuff, anyway.) The changeset seems to work fine in 2.9a-3278... there are no direct conflicts with other (post-3193) changesets, either. Maybe give it a shot for a few days, anyway.
(As a quick verification that his changeset works, modify Browser>>openAsMorphEditing: so that hSepFrac is set to 0.5. Then if you shrink a system browser down to its minimum height, the subpanes will still each take up 50% vertically.)
- Doug Way dway@riskmetrics.com
Doug Way wrote:
Dan Ingalls wrote:
We will limit further updates between now and the CD freeze to bug fixes.
The only small plug I would make would be to include Jesse Welton's LayoutFix changeset posted earlier today, which is sort of a bug fix. (It fixes the problems Whisker has with the current LayoutFrame stuff, anyway.) The changeset seems to work fine in 2.9a-3278... there are no direct conflicts with other (post-3193) changesets, either. Maybe give it a shot for a few days, anyway.
Besides addressing (some of) the conceptual problems with SystemWindow layout, it also fixes a concrete layout bug in the FileContentsBrowser and Celeste. In these windows, the bottom pane stuck out below the window frame. So I think it's more than "sort of a bug fix". It fixes a honest-to-goodness behavioral bug.
I also think that the layout offset handling should be made consistent. It's not a behavioral bug, per se, but it's a conceptual bug that I think is all the more important to fix in a product oriented towards beginning Squeakers. (To review: LayoutFrames' bottomOffsets are sometimes treated as offsets, and sometimes as insets. Yuck!) I'm happy to do this, and I'm working on it. All I need is to figure out how to handle object conversion. A word from SC as to whether offsets or insets is the preferred behavior would help, as well.
-Jesse
Jesse Welton wrote:
Doug Way wrote:
Dan Ingalls wrote:
We will limit further updates between now and the CD freeze to bug fixes.
The only small plug I would make would be to include Jesse Welton's LayoutFix changeset posted earlier today, which is sort of a bug fix. (It fixes the problems Whisker has with the current LayoutFrame stuff, anyway.) The changeset seems to work fine in 2.9a-3278... there are no direct conflicts with other (post-3193) changesets, either. Maybe give it a shot for a few days, anyway.
Besides addressing (some of) the conceptual problems with SystemWindow layout, it also fixes a concrete layout bug in the FileContentsBrowser and Celeste. In these windows, the bottom pane stuck out below the window frame. So I think it's more than "sort of a bug fix". It fixes a honest-to-goodness behavioral bug.
(Actually, it looks like someone else already fixed the FileContentsBrowser in 3278. But Celeste was not fixed, and neither was Scamper, so you've still got 2 concrete fixes to your credit. :) )
I also think that the layout offset handling should be made consistent. It's not a behavioral bug, per se, but it's a conceptual bug that I think is all the more important to fix in a product oriented towards beginning Squeakers. (To review: LayoutFrames' bottomOffsets are sometimes treated as offsets, and sometimes as insets. Yuck!) I'm happy to do this, and I'm working on it. All I need is to figure out how to handle object conversion. A word from SC as to whether offsets or insets is the preferred behavior would help, as well.
If SqC doesn't have a strong opinion on this, I would tend to just go with offsets. I believe that LayoutFrames in VisualWorks are always treated as offsets, but I'm not positive... it would be worth checking. (As far as the object conversion goes, wouldn't a single pass through LayoutFrames allInstances take care of it? You wouldn't have to check for class version or anything. Or is the problem that you only want to convert the LayoutFrames that are in SystemWindows, or vice versa?)
- Doug Way dway@riskmetrics.com
Doug Way wrote:
Jesse Welton wrote:
Doug Way wrote:
The only small plug I would make would be to include Jesse Welton's LayoutFix changeset posted earlier today, which is sort of a bug fix.
Besides addressing (some of) the conceptual problems with SystemWindow layout, it also fixes a concrete layout bug in the FileContentsBrowser and Celeste. In these windows, the bottom pane stuck out below the window frame. So I think it's more than "sort of a bug fix". It fixes a honest-to-goodness behavioral bug.
(Actually, it looks like someone else already fixed the FileContentsBrowser in 3278. But Celeste was not fixed, and neither was Scamper, so you've still got 2 concrete fixes to your credit. :) )
I hadn't yet had the opportunity to try the latest changes. Nor had I known about any problem with Scamper layout. There must be some sort of conservation principle at work here... :)
If SqC doesn't have a strong opinion on this, I would tend to just go with offsets. I believe that LayoutFrames in VisualWorks are always treated as offsets, but I'm not positive... it would be worth checking. (As far as the object conversion goes, wouldn't a single pass through LayoutFrames allInstances take care of it? You wouldn't have to check for class version or anything. Or is the problem that you only want to convert the LayoutFrames that are in SystemWindows, or vice versa?)
The tricky bit is making sure that instances are converted when an image segment is loaded, that was saved from a pre-conversion image. At the same time, you must ensure that the post-conversion instances are not erroneously negated again. That's where the class version check comes in. I think I've actually got it working now; I just have to check against the latest changes.
-Jesse
squeak-dev@lists.squeakfoundation.org