Aye, would have been nice to have started by delegating the #drawOn: method,
would also want to delegate #drawSubmorphsOn: as well for doing visuals that
appear above the submorphs.

However, I have gone for the approach of modifying the morph's visual
properties and mostly leaving the draw stuff alone (maybe more complicated).
Many fixes along the "journey" too!

-----Original Message-----
From: squeak-dev-bounces at lists.squeakfoundation.org
[mailto:squeak-dev-bounces at lists.squeakfoundation.org] On Behalf Of sig
Sent: 26 April 2007 11:17 pm
To: The general-purpose Squeak developers list
Subject: Re: Nice Looking Squeak IDE's?


On 26/04/07, Gary Chambers <gazzaguru2 at btinternet.com> wrote:
> Might have one for you soon, need to clear with my employers! It is 
> possible that many people won't like that amount of modifcations that 
> were required (fixes/hacks) but it gives us a nicer environment in 
> which to develop our
> business solutions.
>

There are already something that allows to change visual appearance of UI -
called themes. But i didnt learned them yet. I tried to play with them, but
all what i get - broken scrollbars. they start to draw at right side of
lists, ignoring list bounds.

Im not sure if basic morphs designed in such way, that you can change their
appearance easily. I can tell how i would do things if i'm willing to
customize my controls appearance. First, all UI morphs have some abstract
state - like item collection for lists or pushed/unpushed/disabled/e.t.c
states. There can be infinite number of ways how we can draw a list or
button. One way - is to hack the #drawOn: method of morph we interested in.
Yes, this will change its appearance but at same time we will loose previous
appearance. To avoid this, i think it will be better to remove appearance
responsibility from UI morph, and  pass it to another object, lets call it
MorphAppearance. Then, for most UI morphs the #drawOn: method may look like:

drawOn: aCanvas
| appr |
   self myAppearance ifNotNildo:[ :appr |  ^appr drawMorph: self on: aCanvas
] ...  default draw (if appearance not found) ...

The #myAppearance method must return instance of MorphAppearance, which is
actually draws our morph. It can be taken from some global dictionary, which
holds currently used theme, set by user or something else.. It can be
categorized by morph class (its obvious, you don't want to draw buttons and
lists with same draw functions) or any other way , not really matters. The
matter that in result we'll get a set of UI morphs which appearance can be
changed by few clicks in menu. And no more hacks/changes in morphs code,
because in most cases all we want to do is to change its appearance. - If we
need new cool looking button - just create new appearance subclass then
create new or modify existing theme/style set and apply it to World. Please
note, im talking about appearance as a whole data+drawing method, not just
data. These are colors, border widths, e.t.c - all this is _data_ which are
parts of morph state, but  they do not dictate how it will be visualised.
Different appearance methods may use this data along with other properties
of morph or can totally ignore some of them - like draw rounded corners or
straight, draw borders or not, draw gradients or plain background.. anything
we want.

Please, let me know if anything similar to what i described already exists.
Definitely, there is no need to reinvent the wheel. :)

P.S. btw, such approach will substantially clean the morphs code. For
instance , i'm really curios why Canvas decides how to draw corners by
receiving #roundCornersOf:during: message instead of morph itself.