Difference between revisions of "Themability"
m (Added to Category Themes) |
Stefanbidi (talk | contribs) (Fixed some random "new lines" on the document) |
||
| Line 5: | Line 5: | ||
AppKit should be: | 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 | + | 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". |
| − | 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 | + | 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. |
| − | 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 == | == Requirements == | ||
| Line 21: | Line 16: | ||
What needs to be (roughly) written before any implementation: | What needs to be (roughly) written before any implementation: | ||
| − | # list of all UI elements (not | + | # list of all UI elements (not controls, but all visible elements): ... |
# list of controls and their drawing methods: ... | # list of controls and their drawing methods: ... | ||
# map of what methods should use what UI shapes: ... | # map of what methods should use what UI shapes: ... | ||
| Line 28: | Line 23: | ||
== Random Notes == | == 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. | |
| − | 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. | |
---- | ---- | ||
Revision as of 17:05, 9 September 2006
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 controls, 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