I've always been a fan of color classes for color-agnostic theming, so
I'd like to move them from the background to being fully usable. First a
quick overview (for the lurkers on the list).
A color class is simply a string label attached to an edje state. From
code, an application can specify a given color for that class. All parts
will then be multiplied by this color. Edje provides two methods for
setting the colors, edje_color_class_set() and
edje_object_color_class_set(). The first sets the class in a global
context (for the current process), while the latter sets it only on the
specified object. The object context takes precedence over the global one.
The best way to make a theme color classed is to draw it in grayscale,
so the resultant colored image will be as close to the color chosen as
possible. However, there is no way in edje to specify a default color
for a class. In Winter, I have just been setting the color of the part
itself. However, if the color class is then set to a different color,
the two colors a multiplied together. The cc color can't override the
part color, since the part color is used for fading, etc.
So, I have written a patch that adds a color_classes block to .edc's:
color: 229 239 255 255;
color2: 0 0 0 0;
color3: 0 0 0 0;
(color2 and color3 are for text outlines and shadows)
This block can be placed almost anywhere in the .edc, but is actually
global to the file (much like images are).
Now, when loading up the .edj, I originally had it setting the cc on the
new object (as opposed to the global context). This would prevent on
theme (say the pager module) from changing the color of another (e.g.
the border) if they were loaded from different files. However, the next
step is to create a dialog to set color classes. When one is changed, it
would be quickest to just set the global cc to that, rather than running
through all the objects and setting it at the obj level. BUT, since the
theme specified cc was being set at the obj level it would override this.
So, I'm not sure how best to do it. Either we load the file level cc's
into the global context (and suffer collisions), or we need a new level
of precedence. Something like: edje_file_cc < global_cc < object_cc.
What do ya'll think?
Also, i would have thought that this patch would break backwards
compatabilty, but old edjes *seem* to work with the patched libedje...