Vincent wrote:
> Hey,
>
> before putting that in bugzilla, here is what I obtain with the following
> code:
>
> [code]
>
> o = evas_object_gradient_add (evas);
> evas_object_gradient_fill_angle_set(o, 90);
> evas_object_gradient_fill_spread_set(o, 1);
> evas_object_gradient_fill_set(o, 0, 0, w, h);
> evas_object_gradient_clear(o);
> evas_object_gradient_color_stop_add(o,
> 255,
> 0,
> 0,
> 255,
> 2);
> evas_object_gradient_color_stop_add(o,
> 0,
> 255,
> 0,
> 255,
> 2);
> evas_object_resize(o, w, h);
> evas_object_image_fill_set(o, 0, 0, w, h);
> evas_object_move (o, 10, 10);
> evas_object_show (o);
> [/code]
>
> the result:
>
> http://www.maths.univ-evry.fr/pages_perso/vtorri/files/gradient_bug.png
>
> that is, there is a red vertical line at the left of the gradient, while
> that line should be at the right (imo)
>
> is it a bug ?
>
> Vincent
>
Since we've been dragged back into gradient land recently, I went ahead
and 'fixed' this 'bug' and a few other minor such grad things. But before
finishing with this, I thought I'd mention an aspect of grads that people might
feel needs improving - namely, the issue of how to specify 'stops'.
A common, or 'standard', way to do this is by defining a color (or alpha)
stop to be a color (or alpha) plus a 'position' in [0,1], not like the current
description of stops. This might be a better method for defining gradient stops
in both a visually intuitive sense, and for creating gui widgets to
interactively
create grads/stops.
Now, one could replace evas' current method with this, or one could extend
evas to support this by adding an api func of the form:
void evas_object_gradient_color_stops_set(obj, Evas_List *stops);
where here 'stops' would be a list of Evas_Gradient_Color_Stop defined as
something
of the form { int r,g,b,a; float pos; } where pos is constrained to lie in
[0,1].
Similarly, one could have a 'get' func to return the list of previously
set such stops. The semantics would be that no copying is done in either set/get
so if one changes the values of some set of stops then one'd need to re-set them
again or one may not trigger an update (and btw, this also holds for the current
'data' set method).
There's a further option here with this - namely, one could take the
r,g,b,a
in the color-stop def to be non-premul, or keep as premul and also have separate
alpha-stops as is now done, ie. also have an Evas_Gradient_Alpha_Stop of the
form
{int a; float pos;} and set/get such a list of alpha stops.
So, if anyone has any comments, suggestions, issues.. *anything* with evas
gradients -- now would be a good time to pipe in. :)
____________________________________________________________
Click here for great computer networking solutions!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMRKoGF8NN0xr9D572Uk2zb0l4dgt7e5fHRu1AuxxDgFh/
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
