Sig,
Agreed, the gratuitous "you can always keep your changes in your image" is better left unsaid. Or is it? Some days I think that is precisely what needs to happen: a group of people could form with the goal of cooperating to build a new Squeak with a reasonably modern GUI, as much ANSI compatibility as they can manage, a clean compiler, clean collections and streams, and ideally with version control that is more formal than anarchy, but provides a way for work like Zurgle, Gary's efforts, and a foundation like you are trying to create to actually become adopted.
Pavel's kernel work might be a big help. New versions would be synthesized by assembling packages. Gary seems to have mastered the art of debugging the user interface, which would enable the kinds of changes you want to make. If he has not already done so, hopefully there are some abstractions that would help others move existing code to a clean framework. I have a few thoughts on graphics. Like you, I care about other devices (printers) and have adapted my coding to greatly cut down on the ugliness of debugging graphics, but not at the level that Gary must be working.
Releases could be planned by functionality to be included, in the following sense: to protect all interests, there should be a way to tell people with really weird ideas to "go away," but the focus should be on turning ideas into benign hooks to allow new packages to install and work or fail on their own merits. Where possible, anything that is included should have tests. Hooks might need to be reviewed after some time passes to see whether they have gone unused, and sun setted if they are simply taking up space. OTOH, if they are packages that never get installed, they would be self-cleaning. I suggest formalizing hooks up front to easy adoption in the new package's future.
As much as I hate to talk about creating yet another fork of Squeak, I think the time has come for a bunch of like-minded people to "keep changes in their own image." We would simply be doing what the community suggests ;)
Bill
========================== Igor Stasenko siguctua at gmail.com Tue Aug 28 14:09:28 UTC 2007:
Well, i agree that problems must be described precisely and also possible ways how to solve them. But i doubt that someone except me (or others who look forward to support GL rendering) will support the changes. A most 'killer' arguments always be: it works fine now, why do we need to change anything? And then: you can keep your changes in your image.
And such position doesn't helps with moving forward for the benefit of all.
You can reread my early notes on all of this. http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-April/115907.htm... I described most of my problems there :)
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029