Themability
Audience of this article: developers, theme creators
Introduction for developers
AppKit should be:
- aware of theming - presence of theming extension in AppKit
- polite to theming - use only theme-delegated class for UI drawing
Having GUI without 1. and 2. is selfish and it is like saying: "NeXT UI is the default, if you want yours, you are free to dig through the sources and create your hack".
Considering KDE/GNOME/etc, we can have themes that simple by providing a "pixmap theme engine" on one hand. On the other hand, by having that "UI drawing delegation" we keep open door for non-pixmap-based themes for those who know how to code and perhaps know how to optimise their themes.
Requirements
What needs to be (roughly) written before any implementation:
- list of all UI elements (not controlls, but all visible elements): ...
- list of controls and their drawing methods: ...
- map of what methods should use what UI shapes: ...
After this list is completed, then implementation of themability support can be started. This list can also provide base for future GNUstep Themability documentation.
Random Notes
- Then GUI should not use drawing by using bezier paths nor DPS operators, it
should use ONLY functions from the "theme class". With this, complete themability can be achieved without it being a hack, as it is now. This desing is much cleaner and straightforward. Theme creator does not have to dig into the AppKit classes to find out "what should be overriden to make the theme work", moreover the theme developer will not end by uncomplete theme, as he knows everything that he should implement.
- It is not easy for the average user who doesn't know how to code. Whereas with KDE/GNOME/etc it's a matter of creating a few textures and pixmaps etc.
See also: Camaelon