Difference between revisions of "Themability"

From GNUstepWiki
Jump to navigation Jump to search
m (Added to Category Themes)
(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
+
# aware of theming - presence of theming extension in AppKit
* polite to theming - use only theme-delegated class for UI drawing
+
# 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
+
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 controlls, but all visible elements): ...
+
# 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
+
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.
+
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:

  1. aware of theming - presence of theming extension in AppKit
  2. 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:

  1. list of all UI elements (not controls, but all visible elements): ...
  2. list of controls and their drawing methods: ...
  3. 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