This is a rather strange thread.

Conceptually, the Zurgle project is intellectual fluff. There is really no
value there. It just sort of pastes some bit maps here and there on window
frames and controls (or allows you to draw them differently, take your
pick). There are no alternate means of interaction provided, and as it
stands is just a whole lot of hack. That is not to say that it's not a lot
of work to make it look and act that way, just that there is nothing that
makes Squeak have a better interface paradigm.

One of the reasons that it's a big mess that it tries to maintain backward
compatibility. One of my main concerns when I started was that I wanted to
be able have the code "just work" with all of the other goodies and packages
out there, and projects that sit on Bob's Swiki and various other code
repositories. Consequently, I couldn't really deprecate any of the standard
SystemWindow methods, but rather had to redirect them when they talked to
window frame components. As you know, this limits how much refactoring you
can really do.

Sure, you could refactor everything and do fixups in the image, but everyone
else's code outside of the image breaks. To me, that's unacceptable as there
is no huge benefit to having the refactored code in the image, and just adds
to the angst of the coding on quicksand feel that Squeak has. If you're on
the outside and you write code, it breaks on things that you don't even know
or care about.

I think the only conclusion to draw for the 3.2 image is that Zurgle is an
ugly goodie that you can add to your system to make it look more
conventional. I've found it useful, but I have a very specific set of
requirements to measure it against.  Hopefully over time we'll have more
than the Luna look available, so those offended by all things Redmond will
be able to sleep at night. I would anticipate that when I go to add another
look, a small round of changes will have to take place. The code is pretty
young, and probably needs to grow up a little.

For me, it's important that 3.2 ships sometime soon, rather than grafting
bits and pieces of code here and there. Certainly changes at the core like
refactoring SystemWindow need quite a bit of testing (which means delaying
ship time) and its not clear what the benefits are (the only reason I
refactored SystemWindow at all was to provide a hook for other code to get
at it).

Going forward, in the modular image age, the whole Zurgle project is simply
another module that you call into your image. I think one the biggest
benefits of the modular system is that the "base" image should become very
well defined, and the base platform that we build on will become more
stable.


Jim


----- Original Message -----
From: "Andreas Raab" <Andreas.Raab at gmx.de>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Monday, May 20, 2002 4:42 AM
Subject: RE: About Zurgle


> Stephane,
>
> Just briefly:
>
> > Does a graphics or window guru can assess if these changes
> > would be worth to be integrated?
>
> I share Jim's opinion that a bit more radical approach would actually
> have been useful. The changes add quite a bit of complexity to
> SystemWindow in such that they duplicate various responsibilities and
> (at least by my glancing over it) it looks like those shouldn't even be
> present in SystemWindow at all if a window frame handles them.
>
> So, Jim, are you up to a little more agressive refactoring of those?!
> Basically, taking out all the stuff that should be handled by the window
> frame into the window frame and only leave a few high-level protocols in
> SystemWindow itself?!
>
> Cheers,
>   - Andreas
>
>