Themability - Revision history

Fred: /* Random Notes */

2010-11-15T09:01:12Z

Random Notes

Cbv: Remove 'see also'

2006-09-09T21:04:03Z

Remove 'see also'

Stefanbidi: Fixed some random "new lines" on the document

2006-09-09T17:05:27Z

Fixed some random "new lines" on the document

Cbv: Added to Category Themes

2006-03-31T16:58:26Z

Added to Category Themes

Stefan Urbanek: /* Requirements */

2005-02-16T15:03:37Z

Requirements

Stefan Urbanek at 14:59, 16 February 2005

2005-02-16T14:59:41Z

New page

''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: ...

== 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]]

← Older revision		Revision as of 09:01, 15 November 2010
Line 27:		Line 27:
	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.

		+	== Available Themes ==
		+	For a growing list of available themes see [[Themes]]

	[[Category:Themes]]		[[Category:Themes]]

← Older revision		Revision as of 21:04, 9 September 2006
Line 27:		Line 27:
	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.

−	~~----~~
−
−	~~See also: [[Camaelon]]~~

	[[Category:Themes]]		[[Category:Themes]]

← Older revision		Revision as of 16:58, 31 March 2006
Line 41:		Line 41:

	See also: [[Camaelon]]		See also: [[Camaelon]]
		+
		+	[[Category:Themes]]

@@ Line 5: / Line 5: @@
 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".
-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.
 == Requirements ==
@@ Line 21: / Line 16: @@
 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: ...
 # map of what methods should use what UI shapes: ...
@@ Line 28: / Line 23: @@
 == 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.
-* 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.
 ----