The drupal color module, if utilized, is one of the most powerful modules in a theme developer's arsenal for extending their design. I feel that this module deserves attention and has the potential to expand.
As a drupal themer who has experimented with color themes and the color.module internals I have bumped into things that would really improve the coloring experience and the module's power/usefulness.
What can be changed with color.module now?
-
Tools for creating the perfect color set
I think we need support for more shades and harmonies. Proposed solution(s):
- Below the color wheel offer buttons to Lighten, Darken, and Randomize current color.
- ? Adventurous people can click a "Randomize scheme" button which generates random hex seed that can fill in the labels with shades of the color.
- Support for Color harmonies of a current color.
- Beside the color wheel there will be a color suggestions panel of 4-6 boxes that the themer can then drag-n-drop to the color fields on the left. Below this panel can be a select box for users to discover more colors harmonized or shaded.
-
Under the hood
Keep the color changing within base_image and the CSS file. With support for unlimited defined colors handled through color_get_palette(), theme developers and webmasters will not have to have _color_shift() handle colors they wish to control.
theme_color_scheme_form() will have support for an optional custom preview.inc template, darken/lighten/randomize buttons and a “Color suggestions” panel.
New functions to create generate color harmonies and shade sets (for color suggestions panel), and functions to darken and lighten based on current color.
If color.module is available for current user theme, hook_user() an field for the user to choose from color sets.
-
Support for unlimited custom colors
Color labels can be misleading. Currently the only available colors are "Base color", "Link color", "Header top" and "Header bottom". I believe that this can be misleading, as there is no way to determine with relative certainty what color will be placed where. Proposed solution: Allow the theme developer to declare an array of "color fields". This would allow use of unlimited custom colors.
For example, a color.inc can contain an
$info = array('fields') => array('background', 'left sidebar background', 'right sidebar background', 'left sidebar border', 'link rollover color' 'link visited color')- This can allow advanced color themers a more granular approach to providing pre-made color.module themes -
Allow more gradients
Currently there is only support for one gradient. Proposed solution: Allow theme developer to specify multiple gradient arrays in color.inc.
-
Allow support for more complicated previews
Previews do not always hold true to the look of theme. Proposed solution: Allow for a custom preview.inc theme for more complicated previews
-
Undo/Redo options
Allow color users to undo mistakes by scrolling through past selected colors.
-
Allow webmasters to create new color sets
Let webmasters demonstrate their color creativity and customize themes to what they need. There is a variable_set() function for a reason, let's use it!
-
Allow ranks permission to choose color sets
Registered/anonymous users can be allowed to choose from color sets (pre-made and webmaster-made) if allowed in the permissions.
-
Proposed mock up
Comments
There is already
There is already a DROP task for this. And I do not, frankly, see how this is more than a DROP task— how could this take an entire summer?
You never know. I looked at
You never know. I looked at the code for color.module and it looked more complicated than most of the other code in core. Yes, I've read all the code in core.
Not really...
Ok, looking complicated has nothing to do with it. It is really not that complicated at all. You want to see complicated, look at the first few lines of search.module. ;)
This is
Extremely hard.
This is way beyond the scope of a DROP task (sorry :D).
This does deserve to be a summer of code project as it could take a very long time to get everything right.
Especially if we have per-user color schemes :D
Needs other modules to work
I'll be minimally extending the color.module for Views as Web Widgets, some additional base images will be added for the embedded widgets. I tried it before with some experiment and it works. However I also stumbled the same problem, its all of nothing. To provide a per user support it need help from the file.module and other modules, primarily the need to provide per user file management not only to uploads/attachments but for the misc, themes, scripts as well as something like per_user_hook_file so other modules can also use it.
A user may not have the
A user may not have the ability to create their own color set. In the User table, is there space in the theme or data column for a name/ID of a chosen (included/webmaster-made) color set?
Hm, I wouldn't put this in the user table
The user table should be reserved for properties of a user themselves: name, email, etc.
I'd create a separate table to store user-color combinations, and join to the user table via foreign key.
Also
I am willing to mentor
Is integration with the
Is integration with the Adobe Kuler API a possibility?
http://labs.adobe.com/wiki/index.php/Kuler
Kuler is a color theme sharing utility.
It would be wouldn't be hard
It would be wouldn't be hard to put this in code. The problem, it probably isn't open source. However, API's exist for someone to use them, and I don't think its against the rules to use an API of a proprietary app (Druplicon v. Google Contacts API Integration). There is also the logo that they require you to place on the page before using the colors. That said, if it'll help people generate colors I don't have anything against putting it on the list.
It would be implemented through the palette on the right, as that part is highly likely to be AJAX because processing the colors is easier in PHP.
APIs
It's legal to make web service calls against a 3rd party service even if that service isn't open source. It's not legal to mix PHP code that is non-open source with that which is GPLed.
The logo requirement, though, could be a show stopper. Even if legal, it's bad form to require a user to post a badge in order to use a module. I'm actually not convinced that it's legal if the module is GPLed. Let's just avoid it and not deal with that issue. :-)
Nitpicking
Well, technically, it is. You're just not allowed to distribute that code - as long as you keep it private, you can happily mix proprietary and GPL stuff to your liking. Not that anyone should do that, because it's not only pointless but also dangerous in case the code is unintendedly distributed by people who don't know about these implications.
Some changes
It could also allow
It could also allow different color schemes for different pages, so all pages of node/* have one scheme and pages of foo/bar be another.
Would it be
Would it be possible/feasable to make the
theming systemcolor module based off of SVG. Use the SVG file for the theme base, make changes to it from the scheme settings, produce an image from the SVG and splice it up? There could be another file with information about the SVG and what is customizable in it.No SVG
An SVG builder and rasterizer is a couple of SoC projects all on its own. It's way too big to tuck into color.module.
We could use a plugin such
We could use a plugin such as imagemagik (http://www.imagemagick.org) which has support for SVG to handle the dirty work and have "template" svg files which are filled-in with the settings... It could also be used to generate a custom logo/title image with the site name. Although this is still may be too big for an SOC project.
I was thinking that SVG files could offer more flexability rather than working with PNG files and painting a background (i believe thats how color module works, correct me if i'm wrong)
Custom colors
Instead of allowing additional colors, I'd suggest just making the entire array configurable. If I want to only have 3 configurable colors for my theme, none of which are text color, I should be able to do that.
Regarding the last point, to clarify, that would be similar to how users can select their own theme? They'd be able to select theme and "skin"?
Otherwise, this sounds highly cool. :-)
User theme selection
If current theme uses color.module && has permission, he can choose one of the theme's color sets or "skins". You could expect to find it near the user theme selection.
nice
This is one module I'm looking forward too. The current color.module limitations force you to build a theme for color.m rather than you can use color.m for any theme.
It would be great if the code for color7 could also be released in a color-advanced module for 5&6.
peach from All Drupal Themes!
Running SooperThemes Premium Drupal Themes