Gustavo wrote:
> On Sun, Jul 20, 2008 at 8:58 PM, Peter Wehrfritz <[EMAIL PROTECTED]> wrote:
>
>> Gustavo Sverzut Barbieri schrieb:
>>
>>> On Sun, Jul 20, 2008 at 8:29 PM, Peter Wehrfritz <[EMAIL PROTECTED]>
>>> wrote:
>>>
>>>
>>>> Jose Gonzalez schrieb:
>>>>
>>>>
>>>>> (4) Extensions to the current rectangle obj api:
>>>>> *******************************************
>>>>>
>>>>> void evas_object_rectangle_corner_radius_set(obj, float r);
>>>>> void evas_object_rectangle_corner_style_set(obj, int corner_style);
>>>>>
>>>>> Where 'corner_style' can be one of EVAS_CORNER_ROUND or
>>>>> EVAS_CORNER_BEVEL.
>>>>>
>>>>>
>>>>> void evas_object_rectangle_corners_set(obj, Evas_Bool tl, Evas_Bool tr,
>>>>> Evas_Bool bl, Evas_Bool
>>>>> br);
>>>>>
>>>>> The corners to apply the style to, or leave squared off (default).
>>>>>
>>>>> Rectangles can be filled and/or stroked, but the stroking will be
>>>>> defined
>>>>> to increase inward - though one could also add an api for deciding
>>>>> whether to have
>>>>> it centered on the rect, or increase inward or outward.
>>>>>
>>>>>
>>>>>
>>>> I'm not familiar with evas internals, but maybe it'd be possible to have
>>>> an evas_object_ellipse. I had several demands on irq for that. And if
>>>> corners for rectangles are possible circles or ellipses shouldn't be
>>>> much tougher than that, probably easier.
>>>>
>>>>
>>> There is just one problem to these: resources to implement. :-(
>>>
>>>
>>>
>> Yup, i know that :). I just wanted to mention that there are people out
>> there that do need/want that feature. I personally don't need it and
>> probably many other don't need it either. So I wanted to bring it to mind
>> that there are some people asking for it. Nothing more.
>>
>
> I'd really like to see jose ideas and also filters in Evas.
> Personnally I'll work on filters as soon as I have time, but I'd like
> to see someone taking care of this gfx api... more specifically I'd
> like to see someone integrate some existing gfx api in Evas, like
> antigrain or cairo.
>
Most of the work involves getting this 'into' evas, the actual routines
are
fairly approachable - except for anything to do with thick stroking of arbitrary
polys or paths.. that should be left til later, but hopefully Cedric and Jorge
can get poly filling and also maybe work out a "path" obj api and again a fill
implementation.
I'll get most of the api I proposed in place, with a sample software
implementation to work from -- no filters though, I'm leaving that for you and
Carsten. :)
As to external gfx apis for rendering to evas.. As I mentioned briefly
before, it would be fairly straightforward to have both a "cairo" evas object
and an "agg" one (maybe easier, I think this only draws to mem buffers?).
One just needs a bit of extensibility to the engines to allow for 'object
modules' (since these two would be examples of such). But you can also have it
by getting the 'native surface' stuff finished off -- that would allow you to
use various apis to render to targets like pictures, gl textures, etc. with
whatever api you know that can draw to such one way or another.. you'd just
then need to wrap this better via smart objs (with render-pre funcs) to get
a more refined api if desired.
____________________________________________________________
Click here to compare top medical billing products, get demos, and quotes.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oiDnOGnerZMRqWIR1nfQppMoRKhaO0MAxacJ1whBNtd6Xve/
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
