Improving the aesthetics and usability of Squeak

Andreas Raab Andreas.Raab at gmx.de
Tue Jul 9 17:47:31 UTC 2002


Steven,

[BTW, sorry for spelling your name wrong]

> Yipes! I agree, and I didn't mean to imply anything negative about 
> SqueakC. No aspersion casting was intended.

Hey, you just gave me the perfect excuse to say something I have been
wanting to say for a long time now. So thanks! ;-)

>  > Modules will not solve the problem of integration
> 
> True, but they will make it *a little bit* easier. If SqueakC 
> decides to change a module on which my work depends, it won't
> effect my work *until I want it too*. I can still use the old
> version of the effected module with my project.

That's exactly where the illusion starts. You assume that the "standard
image" will be without that module you are using and that was changed.
What makes you think so? It will be the case that a Squeak version X.Y
will contain modules of versions X.Y. If your module does not work with
them you are in exactly the same situation as you are if you require a
certain Squeak version without modules.

>  > Modules will not solve the problem of what is in
>  > the "base image" and how to find things that are not in.
> 
> True, but that is not what makes it daunting to write an alternative 
> widget set. What difference does it make if you have a great 
> system for finding alternatives to what is in the base image
> if those alternatives doen't exist in the first place?

Wasn't this where this discussion started?! 
To quote Peter Schuller:
> The situation I'm talking about is that there
>*IS* code out there - just not in the image.

> I hope, in the partitioning of the image into modules,
> that part of the intent is to create a Morphic kernel
> that implicitly encourages alternatives to the 
> look and feel of the SqueakC version. If not, then what is
> the deeper motivation for modules in the first place?

Well, there are a *few* more issues involved with modularization than
just skinning ;-) Seriously, if all we wanted is to have different looks
I would not bother with this stuff at all. The point of modules is to
actually be able to do certain (de-)compositions which would be
extremely hard to do without them (if possible at all). That's why I
wrote in my message that modules help to identify problems. Without
identifying them you can't even think about making a clean
(de-)composition in the first place. All you can do then is something
similar to majorShrink - analyze the system every time from scratch,
figure out what breaks if you do XYZ and then cross your finger that you
got everything right. Modules help to keep track of these dependencies
incrementally and explicitly. They don't solve all the problems but they
identify them and that's where their true value is.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list