Having finished most of the theme's design I've been busy slicing and coding the theme. Currently every layout type except triple equal column is finished, so what mainly rests is writing CSS for all the Drupal elements.
Earlier this week I've been trying to make my theme use color.module. Unfortunately this didn't seem to work out as expected. If I understand the features of color.module correctly it allows you to define these "color regions": base, top, bottom, link and text. Top and bottom only seem to work with gradients and link and text for text, so I'm stuck with using base, which isn't sufficient.
So currently I feel that color.module should have the possibility to add "custom color regions" so a theme designer can choose which color regions the user can edit.
Because of these limitations I decided not to support color.module. I did however make a .psd file containing slices with every image that is being used in the layout. This .psd could be used in the future for color.module support because the slices have the coordinates of each image. Because everything is layered it's possible to grayscale them and make them transparent so the image can work with color.module's blending.
I've also been working out a system to allow multiple layouts based on which regions contain data. My approach is very similar to themes like Garland or Zen: in template.php a template variable is added containing a class for the html body tag. This class is generated based on which regions have content. For example, if the left and right sidebar have contant the class will be "sidebar-double".
My theme however introduces a third sidebar (secondary right sidebar). Because the secondary right sidebar can only be used together with the right sidebar and not the left sidebar I introduced the concept of "polymorphic regions". This means that regions can act or be displayed differently depending on the context in which they're generated.
Example: The user adds content (blocks) to the secondary right sidebar and left sidebar, the right sidebar is left empty. Instead of rendering an ugly secondary right sidebar that looks totally out of place (without being "attached" to the right sidebar to which it belongs in the original design) the sidebar will be rendered as a normal right sidebar.
Other example: The user adds content to the left, right and secondary right sidebars. Normally this would narrow the content too much, so this is totally impractical. Instead it will render all three sidebars as three equal columns with the content beneath it (= triple column layout).
Once I've finished the triple column layout and added some additional styling to the sidebar blocks I'll commit everything to CVS, hopefully tomorrow night.
Comments
color module support
You can always calculate matching colors based on a base color. That would be what you do if you edit the PSD anyway(?).
I'm not sure I understand
I'm not sure I understand what you mean.
The problem with color.module is that it lets the user choose:
- base color (the light blue in Garland's case)
- header top (top color of Garland's header gradient)
- header bottom (bottom color of the gradient)
- link
- text
My theme is slightly different in that the header does not use a gradient, so header top and bottom are obsolete.
So, without touching color.module itself I can't provide support for additional user color schemes, not unless there's no problem with having two color choices that do nothing (header top/bottom).
So using the transparency method it's indeed possible to support more than only the base color, but the problem is that the header top/bottom colors are obsolete in my case and there's no way to remove these choices from the theme's configuration page. Unless I'm missing something of course :)
module workaround
Well, you can explore building a very simple module to work around these limitations. You can easily alter out the irrelevant parts of the form.