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.