Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | color.module |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed |
Issue Summary
The current color.module is more of a garland-addon than a useful module for recoloring themes. I know because I've managed to build 5 themes for color.module _despite_ how it is built.
Various parties are interested in recoloring abilities for Drupal for various purposes. For me it's building great-looking themes that are abstracted from colors and given the freedom recoloring stylesheets and complex graphics with accuracy as well as good usability. Other parties are interested in using color.module as a feature on community websites, to enable users to recolor their profile page theme and/or recolor the sitewide theme to their preference.
In order to achieve these things, we need a Color API and some modules that interface with it. To ensure backward compatibility with colorable themes (garland) color.module should be a regular external module so that users can choose to download color module or any other modules that enable recoloring capabilities.
Freeing the color module out of core allows for new technologies to be developed for better recoloring and better writing/rewriting of images, and it will be an opportunity to redo the color module "The Drupal Way".
Comments
#1
+1
It'd be nice. color.module isn't good for core inclusion. I recommend moving to contrib:
- It's not just colors anymore. ("Hot swapping" stylesheets is the new kool)
- We can do core theme patches to help assist in CSS alteration/swapping for themes
Demo of enhancements to color.module, color_soc08. http://www.skiquel.com/lab/drupal-6 (you may have to refresh)
There are other ideas for modifying themes in the works (CSS API, style). As for Color API, it's just colors, you don't interface with 'em.
Color.module should be just for themes (avoiding feature creep). Even if there comes a CSS implementation in contrib that can do it all.
I'd love to help maintain color.module for d6 in contrib, and live up to the promise continuing it in d7.
#2
I'm not a themer, so I wont comment on the theming aspects of this issue or the in/out core question.
I'm maintainer of the (image) CAPTCHA module and at one point I tried to reuse the color picker wheel thingy from color.module for the selection of the background and foreground colors. I soon gave up as I realized that the color picker was too tightly coupled with the theme recoloring functionality of color.module and I didn't want to fork parts from color.module in another module. It didn't felt like good code reuse/reusability (is that a word?).
I just wanted to say that I hope the discussion about color.module goes a bit further than theming, like offering a reusable color picking widget that can also be used by non-theme related modules. You need such a widget anyway for theme related functionality.
#3
I guess there is need for several functionalities that are all trapped in the color module:
1. farbtastic color picker
2. slicing/generating images
3. shifting colors in HSL space
4. rewriting stylesheets. Though in my themes I bypass this last option because it use is very limited. I use some custom colorshifting functions to generate new colors.
#4
When you really think of it, Drupal would be boring if we didn't have this.
Unfortunately, Color.module SoC '08 (Version 1.x) is one of my first modules. It's less hard-coded, however, not core quality.
When Peach mentions it, he makes it sound easier. Basically, I already have the code done, I just can't organize it on my head right.
I will give this a bit more thought.
#5
Looks like we either need to start designing an API/architecture or take a look at the SoC color module and see if it is close enough to use as a basis to clean up and get into core.
#6
I found http://drupal.org/project/color_soc08 to be a pretty good job. Slightly odd in a few places internally, but it did a great job of replacing core color.module.
I've used it a bit. Just needs a broader base of maintainers and a few interested code gurus to push it along.
#7
I'm against the removal of Color module as it's almost the only place where you can quickly get an almost unique design for your site without having to download a contrib theme. People considering other systems, very much love dynamically changing their theme without having to write CSS themselves. I am in extreme support of revamping Color module though. Doing stuff like this would be awesome:
#8
Good point, it's a good start for a demo.
However, can we decouple it enough to provide color.module development in contrib - as a drop-in replacement?
color-ng has shown that this is feasable. Maybe we just have to endorse that. Drupal core gets the basic existing functionality. color.module gets duplicated to contrib? I think the movement to remove it from core is all about getting interested contributors to work on it/support it a bit more.
That is not happening with it inside the core repo.
#9
I'm on the fence about this. On one hand, Color module is a special use case as it is now and is not "core worthy" in terms of quality. On the other hand, color could be a really solid building block piece if better utilized. For example, Seven could use color module and perhaps even graphics such as the AJAX progress meter. See jQuery UI's theme roller for ideas outside of themes. I also like that it may have the most sex appeal for new users.
Perhaps the question here is if there is enough interest in Color module within the core developer community that justifies it staying in. If it is simply stagnating, it would be better off dropped. If champions emerge, it would be worth keeping in. Obviously just my opinion here.
#10
Patches are welcome to improve the color module like every other parts of core. There are a lot of good ideas in this issue, why not trying to put them in motion first?
#11
I personally lack the ability to write a simpletest that will verify that a derived PNG image is what I want.
Therefore I lack the ability to write a patch that is likely to get anywhere near accepted for core.
Therefore while color.module remains in core, I can't see me writing any patches for it.
I avoid patching core on production sites, for upgrade stability.
Instead I've tweaked Color NG instead, even a few accepted patches there. That is interesting, and sorta productive for getting actual results.
Color NG, to my mind was a lot of good ideas in motion. Sure seemed to be a lot of code that could be adapted. But even though I like it, I don't think it's likely to all get into core, nor should it.
I think that those advanced or unique ideas will flourish better outside of core.
#12
I can help with the test, if someone is willing to improve on it.
#13
Tagging.
#14
subscribe
#15
subscribing
#16
Does the above -> won't fix mean that color module is definitively staying in core? I guess thats how it has to be as long as Garland is the flagship theme of Drupal. I don't like garland (anymore) but I understand how the transition from Bluemarine to Garland may have contributed to Drupals succes, so I respect this choice.
I guess I should put my money where my mouth is and start turning some of my ideas into core patches. A themer trying to get core patches in Drupal..... (/starts playing Benny Hill theme).
#17
I think the won't fix above means that without a patch, this won't get fixed. + It's way after code freeze and isn't as critical as some of the other issues so the chances are slim.
#18
There is still chance for having color module fixed in Drupal 7. Please help testing the patched version.
#19
Changing to 'active' for 8.x.
#20
wow, I cant believe I didn't tag it right!
#21
#693504: Color.module does not support more than 5 colors and has hard-coded labels
#22
I'm trying to tackle this for D8. First big issue is #1064484: Support RGB/HSL in color module, which might result in some drastic changes.