I’ve seen some applications with really cool window shapes that are nonrectangular. How can I add these kinds of window shapes to my application?
This is the fifth and final installment in our look at how to create a skinning engine for an application that requires a customized or nonstandard Windows interface. We’ll take a look at an approach to specifying a skin manifest that is used by the skinning engine to determine what elements comprise the skin, where they should appear on the application window, and so on.
When I first tried out first-person-shooter games such as Doom or Quake, I was amazed at the detail. Previously, most games rendered characters, icons, or other game elements as two-dimensional images. Although they would move and rotate, the scenery within the game often seemed to be a painted backdrop to the characters themselves. Realism was sorely lacking.
What Doom brought to the immersion gaming genre was the concept of a gaming engine. The engine had the ability to process a specification and render the images in such a way that the user could perceive depth, lighting effects, and an ability to exploit the z-axis of three-dimensional space for such things as walking up steps, and the like. The engines are often very sophisticated pieces of programming using state-of-the-art techniques for rendering graphical images in such a way that the human eye is fooled into thinking that they are seeing something real. The engine requires a specification or map that describes the “world” of the game. The world is most often created by a gaming designer who might not even have a programming background—they can be skilled only in graphic arts or in character design.
In the same way that engines in modern games uses maps to describe the world in which the user inhabits, a skinning engine can make use of a manifest that describes the layout of a skin. Fortunately, a skinning engine is a vastly simpler undertaking than building a modern gaming engine. Likewise, a skinning manifest is simpler than a gaming map. But conceptually, they are very similar.
The first task in defining a manifest for a skinning engine is to capture all of the capabilities of the skinning engine in a catalog. This catalog lists each capability and how it is used as well as interactions with other items. For example, a skinning engine may allow for the placement of graphical buttons on the application window at a specified coordinate location. This might include details such as the graphical images for the normal, depressed, disabled and focused state of the button, preferred size, x/y origin, and an action to perform when clicked.
Often when designing a skinning engine and manifest, I've found that iteration takes place between the two. The engine design needs to support as many behaviors as is necessary to provide for a rich skinning experience while the manifest must be able to capture the intent of the designer in such a way that the engine can understand the designers wishes. However, the manifest has to capture this intent in a structured manner in order for the engine to process it efficiently. Sometimes the manifest has to be altered due to limitations in the engine, or to ensure that a designer can understand how to specify what is desired.
Ideally, a skinning system would provide for a manifest designer. This tool would be a graphical system used by the designer to specify what is desired. It would translate the graphical specification into a manifest used later by the engine. However, many skinning systems I've seen either provide a very limited designer or no designer at all -just the manifest file format. This is probably due to the expense in creating the designer for the skin developer and the fact that skinning an application is a more limited domain than creating a gaming world. So far, I haven't had the need to go so far as to create a designer, but if your skin gets complicated enough, it may warrant one.
Once the analysis and iteration is complete on the capabilities of the engine, the manifest file structure can be defined. Given the amount of variation in skin engine capabilities and needs, it's impossible to define a single manifest format that will work for all cases. For my own skinning engines, I've found that using XML is a great way to structure the manifest. It has the advantage of being hierarchical, can be processed quickly by off-the-shelf software such as the Microsoft XML Parser that comes with Internet Explorer, and is very human readable. I've stayed around from binary formats since the space and efficiency gains never seemed to outweigh the effort. However, it might make sense in some cases where the skin needs to be encrypted or protected in some manner to create an XML to binary converter that is run across the manifest once completed.
Below is an example of a part of a manifest I created for one such skinning engine:
?xml version="1.0" encoding="ISO-8859-1"?> <skin> <fonts> <font id="Font1"> <face>Tahoma</face> <pointsize>8</pointsize> </font> <font id="Font2"> <face>Tahoma</face> <pointsize>8</pointsize> <bold/> </font> </fonts> <app id="App"> <background> <transparency>FF00FF</transparency> <file>appbackground.bmp</file> <hstretch> <x>418</x> <width>50</width> </hstretch> <vstretch> <y>189</y> <height>66</height> </vstretch> <grippers> <gripper>591,0,591,11,624,30,632,30,619,12</gripper> <gripper>633,426,623,426,603,454,615,455,624,447</gripper> <gripper>0,425,11,425,36,455,22,455,9,448,3,436</gripper> <gripper>45,0,0,39,0,30,11,11,41,0</gripper> </grippers> <margin> <left>24</left> <right>35</right> <top>46</top> <bottom>96</bottom> </margin> </background> <size> <width>1059</width> <height>758</height> </size> <menu> <font href="#Font1"/> <bgcolor>8AA1C0</bgcolor> <fgcolor>000000</fgcolor> <highlightbgcolor>000000</highlightbgcolor> <highlightfgcolor>FFFFFF</highlightfgcolor> </menu> </app> <buttons> <button id="MaxApp"> <image> <width>21</width> <height>23</height> <transparency>FF00FF</transparency> <file>maxbtn.bmp</file> </image> <actions> <action> <onevent>leftmouseclicked</onevent> <object>App</object> <message>Maximize</message> </action> </actions> <origin> <x>539</x> <y>12</y> </origin> <tooltip> <desc>Maximizes application window</desc> <font href="#Font1"/> </tooltip> <pin> <left>100</left> <right>100</right> </pin> </button> </buttons> </skin>
Looking through the XML above, you may notice that I've grouped the manifest by graphical element. Here are some notable points about the design:
- Font specifications are listed at the top and referenced later in the skin by their ID. This saves having to specify the same font over and over again. It functions as a very simple embedded cascading style sheet.
- The <app> element indicates information about the main app window itself.
- The <gripper> element allows for specifying "hot regions of a graphic. In this case, grippers define places where the user can grab to resize the application window.
- The <button> element allows for specifying the placement, appearance and actions of a graphical button. The <action> subelement is the most interesting. It allows the designer to specify a message to send to another element in the manifest when the button is clicked. It is possible to specify multiple <action> tags for a single button routing messages to multiple elements.
Space prevents me from describing every feature of the skin engine and manifest, but hopefully you get the idea. A skin manifest can capture far more than just the layout of the skin-it can capture behaviors, too. In fact, this is where a skin can get really interesting because you can get as sophisticated as you want in supporting loading external code, running scripts, etc. It allows for extending the functionality of the application through the skin itself and is a very powerful technique.
Mark M. Baker is the Chief of Research & Development at BNA Software located in Washington, D.C. He can be contacted at [email protected].
