Skinning for speed:
Menus are dynamic objects, that is, the width and height of a menu varies according to the content. The same thing can be said of WorkShelf, where the shelf will have different sizes depending on whether it is docked or floating, the number of icon rows being displayed, etc...
The theme bitmaps you provide, on the other hand, are fixed size. In order to map these fixed sized bitmaps onto menus and the shelf, both NextSTART and WorkShelf must stretch and tile the bitmaps in memory as required. The more operations have to be done to expand the bitmaps in memory so they cover the actual menu and shelf surfaces, the longer it takes to have the object ready to be displayed.
You can usually tell WorkShelf and NextSTART to either tile or stretch a bitmap. Use stretch wherever possible since this requires a single operation versus the multiple operations required to tile a bitmap over a surface. Do NOT do what a theme author (who shall not be named) once did: he created a shelf body bitmap consisting of a single pixel (!) and then told WorkShelf to tile the bitmap (!). With a shelf body of 1000x200 pixels, this meant that WorkShelf was performing 200,000 tile operations just to construct the body of the shelf in memory. No wonder everybody complained his theme was slow! If the author had specified Stretch instead of Tile, the whole thing would have been done in a single operation. The problem was later corrected when I spotted this, of course.
Menu button bitmaps have a 'To Body' option. You should use this option whenever possible, i.e.; when there is no separation between menu buttons (flat menu backgrounds). With this option selected, NextSTART stretches the single button vertically in order to cover the menu button area (again a single operation) instead of tiling each button repeatedly until all buttons have been drawn. When in doubt, enable the 'To Body' option and click Preview: if your menus still look the same, then leave this option on. Don't forget to do the same for Inactive Menu button bitmaps if you are using different Active/Inactive bitmaps.
Per Pixel Alpha themes and Win9x/NT4:
WorkShelf v2.0 and NextSTART v4.0 introduce the powerful capability of per-pixel-alpha themes, where bitmaps can be translucent and blend with whatever is on the background.
This capability relies on technology that wasn't available until Windows 2000 was released. You should keep in mind that, although now a minority, there are still a lot of users out there using Win98 and even Win95/NT4. These Operating System versions do not support per-pixel-alpha.
Winstep has always prided itself in keeping its software backwards compatible, that is, it will run as well on old Win95 machines as on the latest OS release. Features that aren't supported by the older Operating System versions are disabled, of course, but the important thing is that the software will run, unlike most - if not all - of the current crop of skinnable applications made by other vendors.
Winstep has therefore developed a mechanism where the theme author can make sure that even users running Win9x and NT4 will be able to use per pixel alpha transparency themes:
The basic foundation for per pixel alpha transparency is the PNG file format. This format was widely adopted for this mainly because it supports alpha channels and, therefore, transparency - unlike the BMP and JPG formats used in previous versions of Winstep software. When a Winstep application detects that it is running on an OS version that does not support per-pixel-alpha transparency, it will try to fall back to the BMP and JPG versions of the PNG bitmaps. For instance, if WorkShelf is running on XP, it will use WsFullBody.png, but, if running on Win98, it will try to use WsFullBody.bmp instead.
The author of a per-pixel-alpha theme should thus always supply BMP and JPG versions of his PNG bitmaps so that his theme remains usable on Win9x/NT4 systems.
This is especially important for every NextSTART component (menus, startbar, etc...) and for the WorkShelf shelf. WorkShelf's desktop modules, on the other hand, will automatically fall back to non-advanced skinning mode, so they aren't a must (but it is always nicer if you provide bmp/jpg versions of the module bitmaps, of course).
Try making the conversion of a PNG base theme into BMP format, you will find that it is probably a lot easier than you thought: flood fill the fully transparent portions of the PNG bitmap with magic pink (RGB 255,0,255) and eliminate any shadows - that should take care of 95% of the work - and then save the bitmaps as bmp.
Attention to detail:
It is often very easy, when making a theme, to fall into the trap of only skinning the objects you use. For instance, if you don't use WorkShelf desktop modules you will feel tempted to make a theme where only the shelf itself has been skinned. Unfortunately there are many users out there who use desktop modules, and what would be a beautiful theme is ruined because WorkShelf displays your great looking shelf and then falls back to displaying desktop modules using the non-advanced skinning format.
Another thing that happens often is the skinner forgetting to check if his theme works well on configurations other than his own. For instance, he makes a great looking NextSTART startbar, but his setup only uses a single row of tasklist buttons. He forgets to check if his startbar will look as good when more than one row of tasklist buttons is visible and, more often than not, it won't. This is extremely frustrating for those who will be using his theme with a multi-row startbar, more so because it is actually quite easy to fix these type of problems - if you're a skinner, that is.
This lack of attention to detail is especially deadly when you are making a port of an existing theme, because once you port and upload the theme to the skinning sites, no other skinner will touch it again. It becomes *your* theme, your responsibility. The perfect example of this (sorry Burt) is the excellent Cabal suite. This is an incredibly amazing theme where the author did everything perfectly - except he didn't skin the desktop modules. The whole theme is let down because of this and, of course, no other skinner has ever made the missing modules.
So, what should you pay attention to when making a theme?
In NextSTART, you should check out the following:
What happens when I drag the top edge of the startbar to display more than one row of tasklist buttons? This is usually the critical bit.
What happens if I set the startbar to be vertical instead of horizontal? Yes, some users like to use their startbar at the left or right edges of the screen - NextSTART provides an alternate set of bitmap filenames for this case (e.g..; StartBarV).
What happens if I set the size of the tasklist and/or quick launch icons to something other than 16x16? Remember, the size of icons for these elements is a per-user setting, therefore not controlled by the skinner. Even if most of us use the default 16x16, there are bound to be people out there using 32x32 or even higher instead.
What happens when I roll up a menu? If your theme is using a titlebar and an endcap, those are the only two items that will be visible when you roll the menu up. They should blend perfectly so that there are no continuity breaks (actually, I have yet to see a continuity break, even on themes made before menus could be rolled up and/or endcaps existed).
What happens if I rotate a vertical menu so that it becomes horizontal? If you don't provide bitmaps specific to horizontal menus (e.g.; HTitleA, HButtonA, etc...), NextSTART will try to build the horizontal menu using bitmaps that were intended for vertical menus! The horizontal menu will thus be as high as the highest vertical menu bitmap (i.e.; it will use the height of TitleA, ButtonA or EndcapA, whichever is bigger) which usually results in extremely thick horizontal menus, with un-matching titlebars and endcaps. Horizontal menus are very powerful and extremely important for reasons I will explain in a separate article, so you really should provide for them.
A bit off-topic, one of the reasons horizontal menus are not more widely used is because not a lot of people actually know NextSTART supports them. This happens because almost no skinner implements menu titlebar buttons these days. If they did, instead of having to rely on mouse clicks on the titlebar or endcap of a menu to perform a specific action (which click does what, by the way, can be specified by clicking on the Mouse Settings button in the Global Preferences tab), the user would have self-explaining titlebar buttons that, when clicked, would close, roll up, rotate or toggle the menu between always on top and normal z-order.
Are your menus always the same width? NextSTART supports dynamic width menus, i.e.; menus that can expand horizontally to accommodate the largest text entry in them. It's easy to provide dynamic width menus, all you have to do is specify left and right tile sections for your bitmaps and, in the Menu Button Skinning Preferences panel, specify a Maximum Width larger than the Minimum Width (we don't want menus spanning the whole screen either, so a maximum width of 240 pixels or so will be fine).
In WorkShelf, this is what you should check:
What happens if I display more than one row of icons at once on the shelf? You can check this out by manually dragging a tab up and down. This usually reveals common problems such as what happens when the skinner includes part of the shelf body in the scroll icons. If the shelf body is based on a gradient, this will work as long as the shelf is displaying a single row of icons, but the background becomes mismatched otherwise. That is why bitmap elements such as scroll arrows are icons instead of bmp or jpg files: so you can take advantage of the icon transparency to seamlessly blend them into whatever background is behind. This, by the way, is also a common problem with the elements that are pasted on top of the NextSTART startbar (such as the Start Button, Quick Launch buttons, etc...), a problem that is also quickly uncovered by resizing the startbar.
What happens if I change the icon size of the shelf elements? Combined with the above, this can be deadly to a theme if the tile/stretch settings of the Shelf body are not set right. Seen it several times before.
What happens if I enable the 3D Frame around the icons? You can find this option in Shelf Preferences, and being a per-user setting that some skinners are not very found of, they disable it. Problem is that this option is enabled by default, and is something that, alone, can make or break a theme if you don't set the frame colors right.
What happens if I set the Shelf to floating instead of docked to a screen edge? Having a shelf docked to one of the screen edges usually ensures that its width will never change, sometimes creating the illusion that bitmaps are all aligned when in reality they only align for that specific shelf width.
What happens if I invert the shelf? Lots of people dock the shelf at the top of the screen, and, when they do, they prefer it inverted. WorkShelf provides different bitmap filenames specifically for inverted shelves, and, if you don't include them, WorkShelf will automatically build an inverted shelf using bitmaps intended for non-inverted shelves. Not a big problem, but if your theme uses 3D shadows, they will now look odd.
What happens if I set the tabs to centered instead of full shelf width? This is a sure way to prevent tabs and shelf body from aligning perfectly. See how your theme looks in this case (I admit, at some point I will have to implement a second set of bitmaps to use as the shelf body corners to cater for this).
Do the colors of the in-shelf meter modules match your theme? Some skinners only use desktop meters, so they very naturally forget about this simple detail. The in-shelf CPU, RAM and Net meter colors are green by default. You can change these colors to match your theme in the settings panel of each of the meter modules. Don't forget you can also specify in-shelf clock and recycler icons to match your theme.
Make sure that tab titles don't overlap critical parts of the tab bitmaps, this will look bad. You have text offsets and maximum text width percentages in the Advanced Skinning panel, use them. Rename a tab to a very long name to make sure that the text is cropped properly in all situations.
A final thing you should do before uploading your theme to the skinning sites, is to clean up the theme folder. Open the theme folder and make sure you are not including un-used bitmaps, fonts or other un-related items. Wherever possible, use a jpg wallpaper instead of a bmp one - this will help greatly in reducing the size of your theme. The user will thank you for a faster download and so will the skinning sites for making them use less bandwidth.
Winstep Xtreme - Xtreme Power!
http://www.winstep.net - Winstep Software Technologies
Last edited by winstep on Fri Mar 24, 2006 3:37 am, edited 3 times in total.