Posted by tonyn on February 28, 2009 at 1:11pm
We need your input here!
Do you think color.module should be apart of core? If so, should it be upgraded from its current state?
Do you find the color.module is tedious or complex? Do you find it beneficial to simple themes? To advanced ones?
Also, for D7, I'm proposing the idea of an open styling system in addition or replacement to color.module. This styling system would allow themers to create prerendered skins and also accept skins from the files layer (meaning it can use color.module schemes).
You can see the progress of this at http://github.com/skiquel/drupal-style/tree (You can also view the style README here) and http://github.com/skiquel/drupal-color/tree.
Style.module (working name)
Style.module is a skinning system that overrides stylesheets in themes.
===========================
File structure
===========================
In every module and theme, the /styles folder includes additional
styles.
Every directory in /styles is a different, unique, style.
When a style is chosen, the style system replaces normal stylesheets
for a theme or module with the styles own.
It does this by replacing files relative to the original theme.
Let's take an example, here's the output of DRUPAL_THEME_DIR/themes/moo/:
+-DRUPAL_THEME_DIR/themes/moo/
|
+-moo.css
|
+-template.php
|
+-moo.info
|
+-page.tpl.php
|
+-images/
| |
| +-header-bg.png
|
+-logo.png
|
+-styles/
|
+-georgia-font/
| |
| +-moo.css
|
+-ocean/
| |
| +-moo.css
| |
| +-images/
| |
| +-background.png
|
+-day/
| |
| +-moo.css
| |
| +-images/
| | |
| | +-header.png
| |
| +-logo.png
|
+-night/
|
+-moo.css
|
+-images/
| |
| +-header-bg.png
|
+-logo.png
If no style chosen, the theme will act normally.
Day and Night styles
the moo.css in the style overrides the theme's
moo.css uses a the custom header-bg.png
Logo.png is replaced by the same
Georgia-font
Uses moo.css with a modification of the site's fonts
Ocean
Custom moo.css with added background.png
# See Tips: Theme stylesheet architecture
=================
Optionally: Files dir
=================
Color.module users rejoice. Styles.module supports all generated images
and stylesheets natively by utilizing the files.
This system treats the files directory as a different layer. The root
of the file directory is treated as like the drupal_path, except for
the permissions.
So YOUR_DRUPAL/themes/moo/style/night
and YOUR_DRUPAL/path_to_files/themes/moo/styles/night
are treated the same.
===========================
Tips
===========================
- You can replace images in CSS as you wish, simple use relative locations.
=====================
Theme stylesheet architecture
=====================
Essentially, you can seperate styling across stylesheets to increase the
theme's flexibility. If you are interested in a good architecture for
stylesheets, see the Zen starter theme. (http://www.drupal.org/project/zen)
If you are distributing a theme and want maximum configurability, you can
for instance move all of your font CSS into a fonts.css stylesheet, and
your images into a images.css stylesheet.
You can also seperate configurable CSS (font, color, background) and
non-configurable. Only the theme developer himself must determine what aspects
of the CSS cannot be changed.
Simply create two files, same statement, but different attributes.
===========================
7.x goals
===========================
- Overriding of .tpl.php files
- In lieu of the stylesheet architecture tip, perhaps a core patch to improve
Drupal's stylesheet caching system.
===========================
Style-compatible extensions
===========================
Color
Create customizable stylesheets and images
- Method of creating customizable stylesheets
- Interface for customizing colors
- Generation system. Output directly to native style.module styles.
Big bonus: Styles will work as long as they are properly placed.
This leaves room for developers to create custom front-ends and applications
for customizing styles through drupal.
========================
CHANGELOG
========================
See CHANGELOG.TXT
Comments
Hard to say
Well I actually know it has been worked on color module in the SOC 2008, but I guess those changes did not make it to core d7 yet (from your post). So actually one has to install the new module to try it out, which I did not.
For the end user color module always was okay to use, I think the ones really important are theme developers. I once looked into it and found: well, this is not an easy task to do, when you want to make use of it as a theme developer. I guess the exact pixel locations of the cut-out png images have to be. Maybe some kind of Photospop-Plugin, to automatize this, would be helpful? Or does this even exist?
The changes that had been made in the SOC looked good and promising (had a look at it once) but also I thought: well, being daring, things like http://wufoo.com/ set the standard in this area, and those are quite far ahead.
What I hate about color module as a themer (not theme developer) is that you cannont make changes to style.css in your theme's folder (as they do not apply) without swithing the theme off and on, so the changes get transferred to the proper 51278145584584.css file in files/css. If there would be a button somewhere "flush css" or even transferred to the admin screen top level (as there are now Buttons to flush the theme cache in Admin Menu) this would improve the situation quite a bit and make me love the module more as a themer.
Life is a process
Life is a journey, not a destination
I think that the main
I think that the main problem with the old color module is, it was made for Garland! It has hardcoded things like gradient-top gradient-bottom, link color, and limited the number of color filled boxes that it will draw.
In order to make the color module such that it will be more easy and more fun to implement it with other designs, the following thinhs _mus- happen:
With the above changes in core the color module would turn from a garland-only module that is near-impossible to implement into a very powerful coloring machine that can be made to re-color ANY design.
I would like to suggest, and support, in moving code from the soc08 color module into the old color module in the form of small patches. Currently I do not think the color soc08 module can replace the old color module due to performance problems and I don't agree with all the changes to the user interface. I also have some new concepts in development that would make the color module much cooler.
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
YO!
Style.module just got an addition.
Without a color.inc needed, it will automatically detect customizable fields in stylesheets. Furthermore, it supports more than colors. This essentially makes color.module obsolete.
If you could help me find a way to implement images that's simple that'd be nice. So far, it's so clean to just handle the CSS and not the image generation.
What we need is a separate module to handle image generation (like an API) quickly made, simple, that can handle image modification. Then we'll have a src file that can fill images and I'll hook it into the style module. The image generation is the biggest pain in the butt.
If we can have style.module read stylesheets, perhaps we can read transparent/fillable images and offer their coloring! Guys, we're gonna make this good and get it in core. If you want to pitch in or watch, get a github account or ping me on #drupal-themes.
hmm
wow, how is that even possible. If that actually works that would be really cool.
How does the module differentiate between colors that are derivatives of other colors and colors that are actually different colors.
For example, a design that is red and orange will probably have a bunch of shades of red and a bunch of shades of orange. How would a module determine which color is the base red color and the base orange color?
I ran into this problem with my own color.module themes and I ended up creating some functions that regenerate derivative colors based on the base colors, its more complex than the code looks, in practice:
<?php
/<strong>
* Shift colors in HSL color space
* @param color
* CSS hex color to be shifted (e.g. #000000 )
* @param $h
* Hue shift, normalized to a fraction of 1
* @param $s
* Saturation shift, normalized to a fraction of 1
* @param $l
* Lightness shift, normalized to a fraction of 1
* @return a string containing a CSS hexcolor (e.g. #000000 )
****/
function color_shift($color,$h,$s,$l) {
$newcolor = _color_unpack($color,TRUE); // hex to RGB
$newcolor = _color_rgb2hsl($newcolor); // RGB to HSL
$newcolor[0] += $h;
//if ($newcolor[0] > 1) { $newcolor[0] = 1; }
//if ($newcolor[0] < 0) { $newcolor[0] = 0; }
$newcolor[1] += $s;
if ($newcolor[1] > 1) { $newcolor[1] = 1; }
if ($newcolor[1] < 0) { $newcolor[1] = 0; }
$newcolor[2] += $l;
if ($newcolor[2] > 1) { $newcolor[2] = 1; }
if ($newcolor[2] < 0) { $newcolor[2] = 0; }
$newcolor = _color_hsl2rgb($newcolor); // Back to RGB
$newcolor = _color_pack($newcolor,TRUE); // RGB back to hex
return $newcolor;
}
/</strong>
* Autohift colors in HSL color space
* @param color
* CSS hex color to be shifted (e.g. #000000 )
* @param $X_min
* Hue/Saturation/Lightness minimum value, normalized to a fraction of 1
* @param $X_max
* Hue/Saturation/Lightness maximum value, normalized to a fraction of 1
* @return a string containing a CSS hexcolor (e.g. #000000 )
*/
function color_autoshift($color,$min_h,$max_h,$min_s,$max_s,$min_l,$max_l) {
$newcolor = _color_unpack($color,TRUE); // hex to RGB
$newcolor = _color_rgb2hsl($newcolor); // RGB to HSL
if ($min_h){
if ($newcolor[0] < $min_h) { $newcolor[0] = $min_h; }
}
if ($max_h){
if ($newcolor[0] > $max_h) { $newcolor[0] = $max_h; }
}
if ($min_s){
if ($newcolor[1] < $min_s) { $newcolor[1] = $min_s; }
}
if ($max_s){
if ($newcolor[1] > $max_s) { $newcolor[1] = $max_s; }
}
if ($min_l){
if ($newcolor[2] < $min_l) { $newcolor[2] = $min_l; }
}
if ($max_l){
if ($newcolor[2] > $max_l) { $newcolor[2] = $max_l; }
}
$newcolor = _color_hsl2rgb($newcolor); // Back to RGB
$newcolor = _color_pack($newcolor,TRUE); // RGB back to hex
return $newcolor;
}
?>
With these functions you can expand the selected colors in the GUI by an unlimited number of derivative colors that are relevent to your design. This can be darker/lighter shades (shift [L] in HSL) of slightly higher/lower color temperatures (shift H in HSL color space)
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
Well. I actually don't think
Well. I actually don't think color.module should stay in core. Only one core theme is using it now and it might well be on it's way out of core too (Garland). That's a lot of code for 1 theme. I would hope that making new core themes re-colorable will not be a requirement, so as things are now, color.module should be removed from core.
If designers of new core themes want to commit to making these recolorable, well then it might be interesting again. But honestly, how feasable is it to make a theme recolorable? Some of the presets in Garland are already ehm, not so pretty. It can be done of course but I feel it would still limit the possibilities of the design. So that's "benificial to simple themes" mostly :-)
Don't you think you'd be better of working on a smarter color module in contrib anyway? Much more room to experiment etc.
Seems like you are proposing two things though. I think I like the idea of additional skins for 1 theme but I'm not sure how much of that relies on color.module? And how different is this from say, having css-only subthemes?
Basically any theme can be
Basically any theme can be made re-colorable with a few days work. I'm going to showcase some of the work on alldrupalthemes.com in a few weeks. I guess it's best we see what sort of discussion that will spark and then we'll make out what goes into core and what not.
color module in contrib would indeed be better, Garland out of core also gets +1 but only if it gets a good replacement. You don't want bluemarine to be the identity of Drupal again.
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
I would have love to use the Color.module more but
I don't have a BS... just a BA
seriously, the ability to make an admin page adjust colors makes so much sense... every designer would like that option (more because of clients than themselves)
however, the inner workings of the module has been so convoluted to me that whenever I pick a weekend to "make it happen" it never gets done.
If there were a non Garland dependency... something that would allow an admin to adjust 5 colors for text fields and 3 areas for bg colors.... with a simple "here's how ya do it" grey scale png sample ... we would have a winner!
8)~
johnvsc@gmail.com
917.676.0677
With all these different
With all these different demands of color module from different people I think it would be best to take color module out of core so that it can be developed and hacked and forked and whatever, without killing kittens (hacking core).
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
crossposting this to some of
crossposting this to some of the other design groups here. Let's get some more feedback on the part of color.module still belonging in core.
kill it
I havent used the colour module once
i cant se any reason for this module to be in core at all - besides the idea of giving the client an opportunity to make you site look ugly.
lets take it out of core where it should be in the first place.
im pretty sure it cold be useful for someone (it could be a really cool option) but imho its just a wast of code in core right now
/morten.dk king of rock
morten.dk | geek Royale
/morten.dk king of rock
morten.dk | geek Royale
I'll be happy to host the funeral
In its brief life, did the color module and farbtastic do anything other than support Garland
@modulist
@modulist
move color module to contrib
It's currently only used by Garland and in two versions no one's extended it to do anything else. Set that little bird free! If it's in contrib hopefully more people will hack away at it and make it more useful.
--
d.o: canarymason
twitter @canarymason
--
d.o: canarymason
twitter @canarymason
Who uses that?
I agree. It's useless unless you never plan to theme your site and settle with the default installed theme. Iv'e seen plenty of sites like that, most are blue (preferred) , the ones that actually used the color module, made the theme look even worse! Remove it.
Signature("http://mhuntdesign.com" , "http://dlc-solutions.com");
Taking it into contrib
Taking it into contrib doesn't mean killing it though. We're going to make it work for more themes by hacking and slashing it into something pretty ^^
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
The use case for the color module is pretty thin
We just don't use it on anything other than a super-low-end site. Any organization site that's large enough to have brand standards would see the color module as frighteningly anarchic. From the point of view of a creative director or brand manager, it would put a dangerous amount of power over the look and feel in the hands of an editor or site maintainer.
For community sites, it's a different story. The color module might be a good tool for customizing profile pages and the like.
I'm against keeping something in core that gets disabled 99.9% of the time. It may have a place to be useful elsewhere.
@modulist
@modulist
http://drupal.org/project/The
http://drupal.org/project/Themes
Color.module, even the old, hard-coded one that sucks is gaining traction. Imagine what we could do if we followed through and abstracted stuff!
I've already abstracted some aspects of CM that can be extremely beneficial in core situations. I don't think it's wise to rule anything out yet.
I'd like to remind you a few
I'd like to remind you a few things.
I too think color.module would be a good contrib module. "Get rid of color.module, I don't know how to use it and won't" isn't contributing much. Either way we want some functionality in place to assure end-user configuration and seemless contrib party integration.
The proposal stated above detects styles in a standardized way. This way people can generate stylesheets and have them detected in a simple way. If you actually do pay attention to core, you would notice the stark theme included in D7. This theme is basically meant to use an additional stylesheet. Wouldn't it be cool to "snap on" stylesheets color.module style without creating a whole subtheme?
IMO it's not the use case of
IMO it's not the use case of color.module that's thin, it's the implementation.
it is very tied to the theme and it is very tied to a few specifics that are a little bit bizarre to me, making it very hard to be genericly useful. I would rather fix color.module so it that it can be a more generic tool and then I think we would see a bigger uptake of its use.
generic colour picker
Can't we create a more generic colour picker - like there is for the date format..
that way designers could just allow not just 5.. but 10/20 fields to be chosen through a colour wheel/palette
We have done this..but it was very ugly, compared to what is available in other cms
Rgds
Simon
Many color.module themes are not contributed
I've worked on projects where the client wanted several themes that implemented color.module to allow users to customize look/feel. These clients love color.module because it allows them to contract only a few themes that appear to be limitless due to their easy customization. These themes are usually not contributed back to the community -- just like 99.9% of all Drupal themes -- because they're central to a client's identity and/or are not properly licensed.
I vote color.module stay in core. As merlinofchaos notes above, it's the implementation (in terms of contributed themes) that's thin, not its use. It's up to us designers to make it more useful by contributing more themes that use it. Developers have given us a great tool; that it's not used is our fault.
Todd Ross Nienkerk
Co-founder, Four Kitchens | IRC: toddross
Todd Ross Nienkerk
Digital Strategist and Partner
Four Kitchens: Big ideas for the web
IRC: toddross
but if we take it out of
but if we take it out of core we can develop it easier.
It will allow the module to evolve naturally like other contrib module, if it's in core we can not make changes after the code freeze.
Another benefit of having it in contrib is that you can modify/fork it for special implementations. We can go as far as turning a garland module into a general theme module but people might get ideas to use it in a special way that applies to their site only, and they will want to be able to change it.
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes
Actually, a
Actually, a well-architecture core feature can greatly enhance contrib potential. This is one of the factors of Drupal's success.
I believe the focus of this should be focusing on creating a better color.module. More clearly, handling the styling and look through overriding and generation of CSS. Not just through themes alone.
Theme Colour Management
I was planning to use color.module for my first theme, but after reading how it works I quickly scrapped that idea.
It would be great if there was some form of theme colour management settings in core that allows me to pic colours as with the color.module, but also define the number of colours I want to be able to customise and let me have a selection of colour schemes.
Even better if it was possible to not just have one custom option, but to be able to save a new set from the theme settings as well as edit existing ones.
This saving/loading of colour schemes could actually be for the whole theme configuration. That would for example make it easy to create and switch between season themes, such as spring, x-mas and so on where for example the logotype, and other gfx, also is different. Then easily switch it back to normal when x-mas is over.
--
/thomas
T: @tsvenson | S: tsvenson.com