Theming in GNUstep ● What is it for? ● It seems there have been three groups calling for theming in GNUstep. ● Some don't like the standard NeXTstep look. ● Some want to blend in with 'native' apps. ● Some just want to be able to customise. ● I just want to popularise GNUstep... so that probably means satisfying all three groups.

Design Objectives ● Ease of use for end users of applications. ● Ease of use for theme designers. ● Ease of use for software developers. ● Flexibility/power/functionality ● Efficiency/speed ● Maintainability/clarity

Ease of use for the end user ● Make a theme a well defined package, so it's easily copied into a standard location. ● Provide a standard way to select a theme from those available in the standard location. ● Provide instant update of running applications to show a new theme. ● Provide a tool to tweak themes for personal customisation.

Ease of use for the designer ● A GUI Application to build themes. ● Instant viewing of the effects of changes. ● Most themes should need no coding. ● Need to support versioning. ● Simplify tiling... split single image into tiles.

Ease of use for developer ● Keep number of methods to a minimum ● Put code in GUI library rather than making developers implement it. ● Group related methods together so that developers can ignore unnecessary stuff. ● Document the new methods as well as we can (we have no Apple documentation here).

The decisions ● Build the theme engine and the design application in parallel ● Make use of existing theming functionality as much as possible ● Make sure that themes can be dynamically switched from the very first. ● Make use of ideas from Camaelon to provide tile based themes to avoid the need for code. ● Provide theme methods to be overridden for code-based themes.

Existing system images ● The GUI library provides system images such as the arrows in menu items. ● System images are retrieved by name. ● We can re-use this mechanism for theming ● We replace certain named images with new versions when a theme is activated. ● We revert to the old images when the theme is deactivated.

Existing system colors ● The GUI library provides a color list containing standard named colors ● Controls get colors from that list to draw themselvses. ● We simply replace the color list when a theme is activated. ● We restore the old list when the theme is deactivated. ● We always deactivate the old theme before activating a new one.

Existing system fonts ● There is a set of named font and font sizes. ● Controls use them to display text. ● They are controlled by the user defaults system. ● So we could have a theme change these. ● Not yet supported.

Existing NSInterfaceStyle ● A mechanism to store a style tag for a control ● This allows switching between a small set of hard-coded behaviors. ● It allows for changes which go beyond simply altering the look of the control. ● But it's too limited for general theming. ● We use it to provide selection between a few standard behaviors. ● NeXTstep, MacOS, and Windows

Existing NSUserDefaults ● The user defaults system can control the themeing mechanisms listed above. ● It can also be used to add new behaviors (like NSInterfaceStyle but more flexible). ● For instance, we have a default to control whether our apps draw their own window decorations or allow the window manager to do it.

New... control specific settings ● Set color to be used by that control. ● Set any interface style/default values to determine behavior of the control. ● Set the tile image to be used for the control. ● Specify which parts of the image to be used. ● Override the methods used to draw the control.

New...Tile images ● An idea borrowed from Camaelon ● A matrix of up to nine images ● Four corner of a rectangle ● Four border sections repeated to fill space ● A central section to be scaled, repeated or omitted ● We actually use a single image split up, so that it's easier to design the tile images. ● A control can use tile to draw itsself.

End user theme selection ● They can specify the theme with a user default, but that's too obscure. ● Standard info panel extended to show the current theme. ● Clicking on that brings up a theme selection panel. ● Clicking on a theme displays information about it. ● Clicking on a button makes it active and/or the default theme for the current application.

Thematic... the design app ● Should be useable to tweak themes. ● But mostly to build them from scratch. ● Provides a way to specify replacement system images. ● Provides a way to specify replacement system colors. ● Lets you set menu style ● Lets you set window decoration behavior. ● Lets you set description, author etc.

GSTheme class basics ● Loads theme from bundle (including executable code). ● Controls switchover between themes ● Notifies the rest of the GUI of any changes ● Changes system colors ● Changes system images ● Changes user defaults / interface styles ● Provides methods to obtain colors, images, and tiling information. ● Load on demand caching.

Theme activation ● We send a notifiction to say the theme will activate. ● We change the user defaults database, sytem colors, system images etc. ● We change the current theme to be the new theme instance (which may be a different class from the old one) ● We update the main menu ● We send a notification to say the theme has activated triggering a redraw.

Theme deactivation ● We deactivate the old theme before activating the new one. ● This sends a notification to say we will deactivate. ● Then removes system images, color list etc reverting to built-in defaults. ● Then removes the current theme instance and reverts to the built in default. ● Then sends a notification to say deactivation is complete.

Themes don't override defaults ● This is an important point... if an individual user sets specific user default values, they supercede the values set by a theme. ● This is because the theming system is careful to set up defaults values in its own domain, and set the search list to search its domain last. ● This was intentional, to leave the individual user in control of their app's defaults. ● Perhaps we should check for, and warn about, any conflicts?

GSTheme low level drawing ● Utilities for low level drawing operations ● Not meant to be overridden ● Tiling a whole rectangle ● Tiling the border of a rectangle ● Filling the central part of a rectangle ● We also have 'mid-level' drawing methods (button borders), which should maybe be recategorised as low-level.

GSTheme drawing methods ● The main API for code-based theming. ● Thematic.app lets you override these. ● The methods may be control specific. ● Controls in the GUI call them to draw themselves. ● These methods call the low-level ones. ● They use tiles, colors, interface styles and images where specified in the theme. ● They fall back on hard-coded drawing of the GNUstep default look.

Named items ● It's not enough to change the look of all controls of a particular class. ● For instance, the OK button in an open panel might want to look different from button cells in a matrix. ● So the enclosing control can name things inside itsself, and look up tiles and colors by name. ● The theme designer can specify individual tiles and colors for named items.

State of development ● The GSTheme framework exists and usable themes can be created with Thematic.app ● The system images, system colors, and interface style information is all themable. ● We need to convert GUI library controls to use it for detailed drawing with named item colors and tiles. ● Currently NSButton and NSScroller/NSScrollView draw themselves using the theming API.

Future work ● We need volunteers: ● Designers to create some pretty themes! ● Analyse individual GUI controls and define individual theming methods to draw them. ● Implement those methods and change the current control drawing to use them. ● Update Thematic.app to support the changes. ● Support setting system fonts in Thematic.app