I alread answered these questions on #lisp, but here goes for documentation purposes.

• I've started 'theming' McCLIM to give it a more modern look (a

darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed?

I haven't looked at pixie, but the way I would do this would be to make handle-repaint call something like theme-handle-repaint with an additional argument of type `skin' or `look' or `theme' or whatever.

Inheriting from existing gadgets and overriding methods doesn't seem like the right approach. I might be wrong of course.

• what is the correct way to add my own widgets? I assume I should

look at gadgets.lisp and start from there.

I think that's correct, yes.

Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that?

Personally, I am in favor of more gadgets. They won't end up in the CLIM package, but that's no problem. CLIM was meant to be extended this way. If you make it a separate system (in the ASDF sense) then people can include it if they want.

• I'm using CLX backend and default/freetype/truetype font

renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before..

I have no right answer for you. Perhaps one day we can have a rendering system that would be anti-aliased and look good at low resolutions. Currently that is not the case.

• right now McCLIMs 'textfield' is vastly different from text fields

in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff?

I would commit those features as changes to the existing text field unless someone can give me good reasons not to.

Regards,