Steven,

> As odd as this might sound at first, I really think there should be a
small
> family of themes for Zurgle that produces the look-and-feel permutations
for
> the current Squeak environment.  Themes that do not require external files
> to work.
>

All that stuff is in there. There is a SqueakWindowFrame that uses all of
the regular drawing stuff. I just don't have an interface element to turn it
on. Obviously you can ship an image with different Zurgle themes built in,
but in my distributions I just included all the bitmap files in case someone
*really* wanted to play. It seemed so simple at first ...

> I too like the colored windows and white backgrounds.  And I like the fly
> out scrollbars and optional buttons.  The provision is already built into
> the latest 3.2 gamma for these themes.  If it were added to Zurgle, then
> general adoption would be more straightforward.
>

Personally, I'm not really concerned about general adoption. My code is much
too heavyweight to throw into a base image (and still very young, it needs
quite a bit of testing before you can really trust it), but seems a natural
(and a good test) for modular Squeak. When 3.2 gets shipped, I'll create an
image with the Zurgle stuff in it and place it somewhere so folks won't have
to worry about all the external files and the nasty file in sequence.

Something Alan Kay said in his talk at Squeakend that  I'd like to adhere
to, is that one person should be able to understand all of the concepts that
are in the image, such as the virtual machine, the garbage collector, etc.
He also said something along the lines that if you build a product on top of
Squeak. then a couple of people should be able to maintain both the
application and the underlying image.  For me, the image has gotten a little
out of control in this regard, as there are many places where an earnest
computer science student would tend to get lost. I think that the Zurgle
code is more obfuscation than anything else, it adds a couple of levels of
complexity to the underlying concepts. Unfortunately the Zurgle code base
has a "hacked" together feel, not something I would tell the class, "Open
your book to page 317 and we will look at how you do theme managers". In
part, this is the "nature of the beast" because of the integration into the
old code in the image.

[Note that you could do that with Berts EdgeImageMorph by saying, "Let's say
that you want to have a typical OS button ... " and get the concept across
about different looks for buttons and such, without muddying the image with
an actual themes implementation.]

In Zurgle, the lack of fly out scrollbars is obviously a bug that I need to
fix (that's why it needs to be tested :-), but all of the optional buttons
and everything still work. Someone might want to go back and skin the
optional buttons so that look like OS type buttons, but the buttons
themselves are still there. (BTW, my feeling is that optional buttons is a
bad interface paradigm that is being used to mask different underlying
problems).

Jim