Ok, to continue with my review and critique of evas gradients.. For the
second (2) aspect of these, we have the following api (set) functions:
Evas_Object *evas_object_gradient_add(Evas *e);
void evas_object_gradient_type_set(obj, const char *type, const char
*instance_params);
void evas_object_gradient_fill_set(obj, Evas_Coord x, Evas_Coord y, Evas_Coord
w, Evas_Coord h);
void evas_object_gradient_fill_angle_set(obj, Evas_Angle angle);
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
void evas_object_gradient_angle_set(obj, Evas_Angle angle);
These were the result of *largely* wanting to extend what evas originally
had
with gradients to support such things as radial (and other) gradient types,
'spread'
modes, and various fill geometries, and to do so with minimal changes in what
was
there to begin with, as simply as possible, and fix some early problems
encountered
with edje grads, and a couple of other minor reasons.
The first api func just adds a generic gradient obj to the canvas - as
was there
from the start.
The 'type' one allows for setting various types of gradients (linear,
radial,...)
and any special parameters they might support - it was the simplest way to
'add' types
of gradients to what was there in evas.
The 'fill' one is a generic means of specifying a fill geometry for the
various
types, analogous to what was used for images - it's good for many types of
gradients
though not always the most natural way to do so for any given type.
The 'fill-angle' one is a means to rotate the gradient geometry around
the fill
origin - a very simplified way to add basic transform-like ability.
The 'fill-spread' one allows for specifying the means to extend the way
the
gradient is rendered outside the fill region.. you have basic
repeat/reflect/pad and
some possibly others. It's used by most all vgfx apis/specs that deal with
grads.
Lastly, the 'angle' one is a means to specify an initial orientation for
linear
gradients - was there to begin with and is basically a high-level convenience
func
to get a kind of alignment 'fitted' to the fill region.
The 'problem' with these, is basically that they are too restrictive in
some
ways, not easy to query the state of the vague 'params', and not very intuitive
for
some grad geometries/types.. nor are they very 'standard'.
Here's a new api I'd like to propose, a fairly 'standard' one:
First of all, remove the generic "gradient" type and have separate api
funcs
for each type that evas wants to support by default - any subsequent custom
types
that may be desired can be added as seen fit, or simply via 'object modules'...
something which is needed anyway and not too difficult to add to evas, though
edje/edc
needs more thought and work to allow for such things.
Let's say we want "linear_gradients", "radial_gradients", and possibly
"angular_gradients", "rectangular_gradients", "sinusoidal_gradients", and
maybe such things like triangular ones or star-shaped ones or one that's like
taking the distance to a line, or other kinds.. though all these can be left
as 'modules'.
We'd then have no more generic "gradient" type, and have instead:
Evas_Object *evas_object_gradient_[type]_add(e);
where 'type' is any of linear, radial, etc. as desired.
However, all the api funcs related to specifying spectra on these would
remain the same, as if these gradient types were derived from a generic base
gradient type.
Then, we'd specify a 'fill' geometry for each type, fitted to that type..
eg. for linear and radial gradients we'd have:
void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
Evas_Coord x1, Evas_Coord y1);
// set the linear grad geometry from point (x0,y0) to (x1,y1)
void evas_object_gradient_radial_fill_set(obj, Evas_Coord x0, Evas_Coord y0,
Evas_Coord rx, Evas_Coord ry);
// set the radial grad geometry with center (x0,y0) and radii (rx,ry)
// In both of these, one could use floats instead.
and if more 'fill geometry' related params are needed or desired for the given
type, then they would be additional.. eg, one could have one to set "foci" for
radial gradients, or an "inner_radius", or whatnot.
We'd then keep the current generic 'spread' api func, but get rid of
both the 'fill_angle' and 'angle' ones.. and instead add one to set a 'fill
transform':
void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
where though an 'Evas_Transform' defines a 3x3 matrix for general projective
transformations, for the purposes of transforming such 'fill' geometries, we'd
use only the affine part - this because only affine transforms are supported
for such things by all the vgfx apis/specs.
In all, for (2) one'd then have:
Evas_Object *evas_object_gradient_[type]_add(e);
void evas_object_gradient_[type]_fill_set(obj, [geometry desc]);
// possibly also 'fill_blah_set' type-specific properties or whatnot.
void evas_object_gradient_fill_spread_set(obj, int tile_mode);
void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t);
That's about it... any thoughts, comments, damnations, whatnot..? :)
____________________________________________________________
Click to become a designer and quit your boring job.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7L984FYZWGReMKirXmF8pRcD6yZyAe4Ksy666i7ONMstJW/
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
