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@lists.squeakfoundation.org [mailto:squeak-dev-bounces@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@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.