So, the talk is about theming. We need to start with looking at what we actually want

to do before we begin the new step. We have, as far as I can see, three main groups of people who are actually interested in themes in the new step. Some of the people who just don't like the way the next step, the new step looks. That's a fairly

vociferous group on the main list. Others are the people who want to have the new step applications running on other systems, blending in with the native look and feel. And some are the people who just want to be able to play around with different things that they can look at, different appearance. So, with theme, I wanted to meet all three

of those groups' desires. So, I started off with looking at what the main basic design objective should be. Ease of use. Firstly, for the end users, the people who are actually

going to use the applications, I want them to look a particular way. Secondly, for the theme developers, if we're going to get lots of people developing themes for the new step, we have to make it easy for them. And third, for the software developers, you don't want it to be a huge overhead to make your software compatible with theme.

Then, lower down on my objectives are the obvious things. The themes actually have to work. They have to do the job. They have to be fast enough. We have to be able to maintain all this theme in our workplace. So, how do we make a theme easy for people

to use? Well, we make it a standard, well-defined package. It's something that you can easily copy from place to place. You don't have any problems installing it. We provide an easy way to select a theme so that people can just play around, try all the different themes available. We make the theme update instant so that your running applications

just change on the fly. You don't have to stop and start applications when you change those themes. And we need to provide a tool so that people can actually tweak those themes and play around with them. From the designer's point of view, you've got to

have some easy way for them to build the themes, and that really has to be a good application. No sensible alternative nowadays. Again, they need to instantly be able to see what the changes they're making to their theme do to the way their application appears. Most things, hopefully, should need no coding. So, it should be good for a designer

who isn't a software developer, someone who's actually good at the artistic side of it, and can put together a theme without having to write any additional code. Sometimes you

do have to write additional code though. When you do that, you need to support versioning because you want to make sure the correct version of your executable is loaded into the system. And one of the ways we're looking at doing themes is by tiling images onto individual controls so that you build a theme out of individual pictures. To do that,

we need to have a nice simple mechanism to define those tiles. I chose to use a single image and divide it up, so you design your button and decide which parts of it are going

to go where. For the developer, we have to keep the number of methods to a minimum to keep it simple. That's a lot harder than it sounds. We need to put as much code into the GUI library to make it standard built in as possible so that the developer

doesn't have to rewrite stuff. We organize things in a clean and simple way with related stuff grouped together, and we'll try and document it. So how did we actually decide

to do it? Well, it's going to be a slow incremental process of getting the theming working perfectly. It's just partway there. So we need to build the theme engine and the tool to design themes in parallel so that as you develop one feature in the theme

engine, you've got the tool to try it all out. We need to use as much of the existing theme functionality as possible, and that's actually quite a lot of this there. We need to design it from the very beginning, instant switching between themes, dynamic update.

And we chose to use the ideas from Chameleon. That's a theme engine produced by the Etoile project. Basically, their concept was tiling perfectly. Define rectangles, define the

images that fill those rectangles, and have various controls in the GUI, draw themselves using those rectangles to tile the left top corner, bottom right corner, filling things in between. And we have to provide theme methods that a coder can actually override

so that they can say, right, I don't like the way this is drawn by fault. I'm going to do it completely differently. Okay, the existing theming stuff, you know, step has pretty much always provided system images. That's things like the arrows in menu items,

icons for file buttons for when you're going to load from the file system, that kind of thing. So we can reuse that mechanism in the new theming API. What we do is we replace the named system images that are built into the system with versions from a

particular theme. And when the theme is deactivated, we just revert to the originals. System colors, much the same as system images. The OpenStack API provided a color

list, which is a list of named colors that the system will use. So it has something saying highlighted control, control that's been highlighted. And when a control draws itself, it looks up one of those colors by name. All we do, we replace that color list when the theme is activated so that new colors will be used throughout and restore

the list when the theme is deactivated again. We always deactivate the old theme before activating a new one and that kind of avoids contributions. System fonts, again,

the NewStep API provides a whole list of standard fonts by name and standard font sizes by name and uses those to decide how text is going to be displayed in various different controls. The user default system specifies which name maps onto which actual

font and material size. We could have a theme change all that sort of stuff. Haven't done it yet. NS interface style, that's a mechanism that was introduced by OpenStep many years ago to control the style of the interface. They used it

for changing the style of applications between NextStep and NextStep running on Microsoft Windows. And it's a simple mechanism where you tag several different style names for different behaviors. And when you set a particular interface style

for a control, then that control will draw itself differently and you've got a hard code of drawing mechanisms in there to do the different look and feel. Because it only lets you switch between well-defined styles that are already built into the

low-level library. It's too limited for general things, but we can use it to switch between standard behaviors such as menus. The NextStep menu is a vertical menu on the left corner of the screen. Mac OS menu appears all the way across

the middle of the screen. And the Windows menu appears within a window. The NextStep is a really major component of this. It allows you to define a

database with lots of different information. And that includes the fonts, the colors, all that sort of stuff. But we can extend it to add more behaviors and default to control whether we have the applications draw window

decorations in the top bar of the window, or whether we let the window know each interface. We can actually use that to control all sorts of detailed individual behaviors if we decide we want them. So what's new in the new

thing in the system? Well, we can set any color to be used by a control individually rather than using the system colors list. So we've got more fine-grained control there. We can set the interface device style for the individual controls and parts of controls. Now, that's always been

possible via the default system, but using the default system is kind of inconvenient. Most users have trouble doing it. They don't know what defaults they can set. They don't know what possible values there are.

So having the theory system do that simplifies it enormously. Setting tile images to be used for a control, that's totally new and adopted from the convenient theme system. And, of course, overriding the

individual methods used to draw a control. So control, instead of drawing itself by using low-level mechanisms as a standard part of the drawing model, we'll use specific methods as a part of the theme system instead.

So tile images. I've already said this before. A matrix of up to nine images. So we can have, say, two rows of three images or two columns of three images or even just four images, but up to nine. So that would define a rectangle with top left corner, top right corner, bottom left corner,

bottom right corner. Then the image in the middle can be tiled repeatedly to fill however wide a control is. The image in the middle on the vertical axis would be tiled to fill up a border on a larger control. And the middle part is either tiled repeatedly to fill a control

or scaled up to do a control or just omitted because this is something that you're going to draw in the middle part with something else and you're only using the tiles for the border. So that concept of a matrix of nine images really works very standard, simple control.

It's not made up of other parts. If something's made up of other parts, obviously you have multiple sets of tile images for each of those sections.

Yes, it's a single image. I think I mentioned that. The idea is that we actually let people design a single image and they can do that in any sort of drawing package and produce a nice looking image for what they want the thing to look like in the long run. Then they go into the theming application with that image

and specify where that's sliced up into nine sections. So that makes it easier to design the nine parts of the tile.

End user theme selection. User defaults are too obscure. It's actually quite simple to set a theme using user defaults. We just set the user default to specify the theme there, but who wants to do command line stuff like that? So what we did is we extended the info panel

that all the NewStep applications use pretty much. There's a standard mechanism within the API for creating an info panel. So all we do is extend that standard mechanism so that it shows the current theme at the bottom of the list and all the other information about the application.

Clipping on the name of that theme brings up the theme panel, which is the icons of all the themes on the left and lets you select on an individual. So you click on an individual theme to select it. Once you've selected a theme, it displays the information

about who the author was, when it was written, any other information that the author wanted to put in there and also obviously changes the way your application looks. There's also a button on that panel that lets you make this selected theme be the default for your application.

Think about it. That's the design application. It should be usable to tweak things because we want it to be nice and simple for people who just want to mess around with their themes. But mostly it's designed for the actual theme designer.

The person who's going to write a theme from scratch is going to put new versions of various different controls and then systematically change colors and that kind of thing. So it has to provide easy ways to replace the system images, to specify replacement color, colors to set the menu style,

to set the decoration behavior, to set all sorts of individual information. The GSB class is the thing that was actually built into the GUI library that the library uses for drawing.

The basic class is responsible for handling loading a new theme from a bundle and that includes loading in new executable code if you're overriding individual methods to draw things differently.

It controls the switchover between themes, that process of deactivating one theme and activating another. It handles all the actual changes in the mechanism of introducing the new system colors and the new images and changing the user defaults. And it provides methods to obtain all the different resources

that you use to draw your controls. And it's designed to be efficient, so it uses load-on-demand caching with nothing in there. None of those big resources like the images are actually loaded into memory unless they're used.

At the moment they're used, they're cached. They stay in memory for the duration that that theme is active. And look up for them. It's extremely quick. The activation process.

Again, we start off when we activate a theme by sending a notification to say that the theme is going to activate. That allows anything else in your application to do any work it needs to do to handle that theme activation. So some of the GUI classes will observe that notification

and will change the way they behave when they see a new theme being activated. But also, user code can handle that. So if an application wants to be able to deal with theming

in a more intelligent way, it can use the notifications to do that. Once we've sent that notification to say we're going to activate a new theme, we change the user defaults, say, to those system colors, system images. We change the current theme, which is a global variable, essentially, so that everything can use this new theme instance, this new object.

We update the main menu of the application because that's a kind of complicated bit where we have to reorganize the menu if we're changing from a horizontal layout to a vertical layout, that kind of thing. And we send another notification telling everything that the activation has completed.

That's the point when all the windows can redraw themselves to take on the new appearance. Theme deactivation is pretty much a reverse of that. We send a notification to say that we're stopping.

Remove all the images, remove the current theme instance, revert to the original one, which might be or will generally be the built-in one. And we send the notification to say we've completed. Right.

I'm putting a whole section on this because it is an important detail that we don't override the default system when we introduce a new theme. Almost all of this standard theming mechanism, all the old stuff certainly is controlled by the user default system.

We avoid overriding what anyone else has set there. So we set our new defaults in a default domain that's at the bottom of the list that's looked at, consulted last. I don't know if everyone's familiar with the default system,

but basically you have different domains that you set defaults in and you have a list of domains and when you want to look up the value of default, it goes down the list, finds the first match. So matches produced by the themes are always the last matches

and someone else can tweak things by setting individual defaults. I don't know if that's the right decision, but that's the way it works at the moment. Low-level drawings, I think, this is a whole new section of the GSB class still.

We provide utilities to do things like tiling the rectangle, drawing borders, drawing the central part. All the sort of basic drawing functionality that you need to use within your theme methods

if you're going to be writing a theme and you're going to be overriding individual methods. This is the toolkit of things you can use to do simpler drawings. You can always use the very low-level API, the NSB to get a path, that kind of stuff, but it's simpler.

The main API for the theming, if you're going to actually implement new controls in the theming system,

we have a list of methods that are essentially designed for drawing specific controls. So, for instance, the button has a few methods that allow it to draw itself using the theming API

rather than using low-level mechanisms. We override those in thematic.app. It lets you add new code to your theme that will override those methods, and the controls call them to draw themselves. So these methods use the tiles, the interface tiles,

and the images that are provided by all the standard theme mechanisms, and none of those overrides that let you theme things. If the tiles aren't there, the colors aren't there, that sort of thing, it all just falls back on the original hard-coded GNU step style.

Named items are a fairly important concept in the theming system. It's not enough to change the look of all the controls in a particular class. The reason for that is that a particular class of control is used in different contexts.

Buttons, for instance, are used throughout the system, and you won't necessarily want the buttons to look the same everywhere that they're used. The OK button in your open panel, maybe all OK buttons, want to look different from most other buttons. The way we handle that is that the enclosing control,

so the open panel, for instance, when it creates a button in itself, it also can assign a name to that button. Basically, it registers that name with the current theme object. That allows the theme designer

to then provide resources specific for that individual button rather than all buttons. Right, current state of development. OK, the framework exists. It's useful. You can create things with the application.

The system images, system colors, interface style information, all that old stuff is there built into the theming system, easily set up. The GUI library controls need to be converted to use the drawing with methods from theme API

to use the named items and the named colors and the named tiles. Currently, NsButton, NsSprl, and NsSprlView are all switched over to use in the theming API, but there's plenty of work still to be done on other controls.

I suppose NsMenu really is controlled by the API as well. So the look of the main menu, we need volunteers. In future, we need, first of all, people to actually start using this

to design some nice themes, partly because we want to have some nice themes, partly because that can show any shortcomings. We need to continue the process of looking at the individual GUI controls that haven't really been themed yet

and define the methods that we're going to use to draw those, these methods that are added to the current theming API. We need to obviously update those controls to use those methods, update the thematic application to support those changes.

We should support setting system fonts. There's not been any call for it yet, but I'm sure at some point in the future, people will want that. I think that's the end. Now, the obvious thing to do at this point is to try and demo thematic in my screen here.

Maybe you can handle this stuff? Do that. This part will work again. Yes, that should do it.

Will that not resize the screen again? Thank you. Sorry, I had to borrow this. Don't have an adapter for my computers or the projector.

Looks good. Let's try to start the thematic application.

Okay. I can create a new theme. I want you to see when you create a theme. First of all is your main window for that theme editor. Up here we have system colors.

That's quite straightforward. It's not the most... Anyway, the system colors inspector lets you select which system color you want to change,

and then you can use a color world to pick a particular system color, say. So the control highlight color might have changed to yellow. Control background.

You can see the instant effect of setting a red background color for all the controls. Pretty ugly, but it illustrates a point. Then we have the system images. That inspector, you get

all the different standard images. So you can find the image you want to change. That one. And double click to get up a... an open panel to select the image if you actually have one on disk and you want to replace it.

Menu inspector lets you, for instance, select between menu styles. So now we have a horizontal menu bar at the top. We have a vertical menu bar again. What are the constraints for a horizontal menu?

Constraints, in what sense? What happens if there are more menu items than in the screen? I haven't the faintest idea, to be honest. I don't know, we've had that for quite a while and I've not actually come across that in practice. We had a discussion about what we were going to do for...

in window menus. Because we've just recently added Microsoft style in window menus and, of course, windows are a lot shorter. So it's actually a real problem in that case in that we're quite likely to have menus where the number of items

won't fit across the width of the window. I think what we decided to do there is have a submenu produced at the right hand side if there were two little space. So you click on that submenu and then get a vertical menu for the extra items.

But that's not yet implemented. Windows, decorated natively or decorated by theme. Unfortunately, that's the one thing that doesn't yet work immediately on the fly. You have to exit from the application again. The reason for that is because

the window decoration stuff is tied in with the back end as well as the front end GUI library. And we've had to change all the back ends as well as changing the GUI to implement that. So that's going to take a little time. Final one along here.

That's miscellaneous stuff. It's where you set who's the author, any additional information you want on the thing, change the icon for the thing, and open an existing one.

Thanks to Ricardo for this one. He didn't want me to show this. It's an old version of this Windows theme. Actually, I've properly modified it a little

so he's not even responsible for any mistakes. The fact is I didn't have anything, I didn't have time to knock up anything myself. I lost it.

It broke. Oh well. I just haven't finished it. OK, so here's an example of an image

and setting the tiling for it. So if you watch the button on the main menu, as I change the position that I cut this image. This has to be always symmetrical? It does in this at the moment.

The back end API doesn't require it to be symmetrical, but the thematic application does.

Anyway, you can see the effect of changing these positions. Basically, we're drawing the border around the outside using this image. Let's see if we can scan this.

Oh, we don't have that one yet. I should go back to...

So, I realize I just went along the top here. System colors, system images, menu, window, and miscellaneous. The rest of this space, the rest of the space here,

this area, is for other GUI controls. The idea is that you go into GORM and edit thematic and just drop other controls in here. So, at the moment we've got a button right in here, a box, and a scroll view with a couple of scroll views.

Now, if you click on one of those, the theming inspector comes up with a whole lot of different options. So, first of all, this tiling. You can control, click on that, and you can select an image to use for tiling.

You can select, in the case of a scroller, different named items here. So, the scroller down arrow is one of those named items that is specific to the scroller.

Select the down arrow and select a different color for the scroller down arrow. There you go. Only if I select the scroller down arrow. I could also, for instance, set a different color for the scroller

as a result of the log. So, you can customize each individual control. You can set the tiles to draw it. You can set the colors. You can set options if they have them.

And this one does. I've forgotten about that. Well, that's good. So, we can have arrows at the same end of the scroll bar. Or at the end of the scroll bar. Just a quick question. Are these colors always opaque?

Or less opaque? They're not opaque. In fact, Ricardo's one that we just looked at was not opaque. OK. So, you can't have alpha? You can have alpha in the colors. In the features too? You have an effect channel in your picture with transparent custom borders in your components?

You could, yes. Now, because the final thing is code. You actually want different code. There are various things you can include in your code.

Extras that you need. So, if you want to add common methods that are shared by different methods within your thing or include extra non-headers. For instance, we are going to be doing a Windows theme. Which we'll want to use the Windows theming API. Which means we're going to need to include their headers.

Global variable declarations. Additions to a make file to build sort. But there's one of your actual theme methods. Draw a button. In view. With a particular style. For a particular state. So, if you click on edit for that.

You get a template method that just invokes the superclass implementation. These template methods are all. Well, in fact, all these settings in thematic are defined in property lists. Text property lists in files in the thematic application.

So, most of adding a new control is very easy. You just change those text files. Anyway, if for instance I want to put some more code in here.

Maybe I won't bother putting any code in here. If I was to put code into here and click on done. Anyway. It would automatically compile that and put it into the theme.

I don't know. That would be kind of fun to do. Do you have any solid colors? Or can you also handle some gradients and predefined patterns? We don't have gradients and patterns in there.

We have just colors and we have tile images. Any gradients should be implemented using hmh every time? Not necessarily. A gradient could be implemented using a tiled image. Or it could be implemented using code. You just override the method to draw the gradient. At some point in the future we might add gradients as an option.

Controlled by the user default option. But we haven't done that yet. I think that probably, really, about covers it. Questions? Any more questions?

What happens if you enter invalid code in the code editor? Just out of interest. Then it will give you a compile error. I'll see if I can do that.

The mouse is a bit sensitive. It's a button to have that sensitive. So if I just enter some rubbish there. Hopefully. Yeah. You get that.

Of course you can delete. Well, you've made a mistake. That's kind of easy. We'll go back in a minute. Somebody tried to convert the comedian theme to the new computer theme? No.

That's probably a good idea to do, but... I mean, it would be nice to have that. Yes, I don't actually think there are very many comedian themes yet.

At least two or three, though, which is a lot. More than we have in the word proper themes. I really like it. I prefer it. All of it is open circle. Which is my personal opinion. Great.

Anything else? More questions? I have no idea what the time is. Will those themes be compatible with other theming engines what they use somehow?

OK, but the way we're going to make things compatible with other theming engines is to actually get in and write code-based things. Most of this is designed on the assumption that what we have using the application is a theme designer.

Someone who's interested in the graphics and is artistic and knows nothing about coding, quite likely. If we want to integrate with Windows, which we do, or KDE or something like that, then we're going to have to use their native theme engines.

The way we have to do that is to go into the code level and use their theme engines from within our code. So we can do that in two ways. If it's reasonably possible, we can use their theme engine to draw into our cues directly.

Directly for the controls. Where that's not possible, because their theme engine just doesn't work that way, what we can do is use the theme engine to draw into a background window

and then take the contents of that window as an image pixmap and use the tiling mechanism to draw that within our things, within our controls. This is a roundabout way that hopefully we don't ever have to use that, but it's a fallback option. So yes, the intention is to write some themes to look like other systems.

You said you wanted to keep the developer API fairly simple, the least methods possible. At the moment, you've only implemented, say, button and scroll bars and things.

How do you envisage keeping it simple as well as the control-specific theming as well? Because you've got zoom checkboxes and radio buttons and they all have their own common boxes and stuff. They all have their own unique methods.

Well, no. Hopefully most of them won't. Because actually most of those things are implemented pretty much as buttons and can be drawn very easily using the tiling mechanism. So the vast majority of cases, what we already have will do the job for them.

What we have to look at are the more complex controls, like where you want a whole panel that contains a browser and various buttons and things to behave differently. One possibility, because of the nature of Objective-C, is that we never provide theming for the very, very big complex controls directly.

All we do is, say, you add a mechanism to replace a class, a control class, that draws itself with a subclass that's completely different.

So we could add a simple API just to effectively replace the class with another version for those controls. So that should keep it, let us keep the count down.

We've got generic stuff that should work very well for all the simple controls. Then we've got a simple mechanism for people to override very complex controls that really need to be done completely differently.

And what we're really aiming to do is keep down the count of methods handling those controls that are in the middle there, that don't really fit into either of those to extreme camps, as it were. So your checkboxes and radio buttons, they'll use the drawButton method to draw themselves, but...

Yes, they'll have a different image. Right, which will be selected somehow with an extra parameter? Well, they already use system images, for instance. The checkbox uses a... So they have named images? Yes, they have named images already, and you just pick the image, replace it in your thing, and the checkbox changes its behaviour.

Before named images, you can add type of theme, and replace the button, which is the mother class. Almost every part of the interface changes, because so many items are buttons, that everything got the window button,

so that's the point where named image is necessary. OK, I think we can call the hold back, and we can get ready for next session.