[UI] State of morphic ... etc,

[Bill Schwab]

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.html
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 at anest.ufl.edu
Tel: (352) 846-1285
FAX: (352) 392-7029