I wrote:
> Carsten wrote:
>
>> .
>>
>>> Exactly. It's useful to have a variety of 'objs', some compound,
>>> some primitive, etc.
>>> I think both an "svg" object (set an svg file/group, support affine
>>> transforms) and a "cairo"
>>> object (an implicit cairo surface to dr
Carsten wrote:
> .
>> Exactly. It's useful to have a variety of 'objs', some compound,
>> some primitive, etc.
>> I think both an "svg" object (set an svg file/group, support affine
>> transforms) and a "cairo"
>> object (an implicit cairo surface to draw on, set updates, etc), and
On Thu, 31 Jul 2008 12:04:39 +0200 "Jorge Luis Zapata Muga"
<[EMAIL PROTECTED]> babbled:
> On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> > As the subject states, let me make a (relatively) short summary of some
> > proposed changes and additions to the evas gfx
On Tue, 29 Jul 2008 15:17:17 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> > fair enough. are co-ords relative to object or canvas-global? i think we
> > possible needs to make this object-relative?
> >
> >
>
> Object relative, ie. rel to obj's coord sys. - that works best for
> e
On Tue, 29 Jul 2008 15:17:34 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>Carsten wrote:
>
> > On Thu, 17 Jul 2008 05:58:24 -0400 Jose Gonzalez <[EMAIL PROTECTED]>
> > babbled:
> >
> >
> >> Ok, now for a proposed api for evas "vgfx objects" -- a very simple
> >> one, but general
Gustavo wrote:
> Join late the discussion and badly starting with a top-post, I think
> that trying to make Evas a canvas that supports both raster, vector
> and maybe other (3d?) is bad, it will increase complexity, decrease
> performance or both.
>
>
Increased complexity, yes - in the s
Join late the discussion and badly starting with a top-post, I think
that trying to make Evas a canvas that supports both raster, vector
and maybe other (3d?) is bad, it will increase complexity, decrease
performance or both.
If we add means to easily integrate with cairo, antigrain or other
vecto
Jorge wrote:
> On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>
>> Jorge wrote:
>>
>>> .
>>>
Let's consider the first part above only, and let me ask you this:
What
are the successful/modern gfx *apis* out there used for building guis,
On Fri, Aug 1, 2008 at 11:21 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> Jorge wrote:
>>
>> .
>>>
>>>Let's consider the first part above only, and let me ask you this:
>>> What
>>> are the successful/modern gfx *apis* out there used for building guis,
>>> what
>>> are
>>> their models, w
Jorge wrote:
> .
>> Let's consider the first part above only, and let me ask you this: What
>> are the successful/modern gfx *apis* out there used for building guis, what
>> are
>> their models, what are their primitives, how do they deal with extensibility
>> or custom rendering. Take a lo
On Thu, Jul 31, 2008 at 1:44 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> Jorge wrote:
>>
>> Some time ago i had another idea that i've been implementing, some of
>> you already know enesim and ekeko, some other dont, let me explain why
>> i think adding this to evas is not good imho.
>>
>> One
Jorge wrote:
> Some time ago i had another idea that i've been implementing, some of
> you already know enesim and ekeko, some other dont, let me explain why
> i think adding this to evas is not good imho.
>
> One of the main reasons of not releasing software is that it evolves
> too fast or it
On Thu, Jul 31, 2008 at 12:04 PM, Jorge Luis Zapata Muga
<[EMAIL PROTECTED]> wrote:
> On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>> As the subject states, let me make a (relatively) short summary of some
>> proposed changes and additions to the evas gfx api -- a
On Thu, Jul 17, 2008 at 10:36 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
> As the subject states, let me make a (relatively) short summary of some
> proposed changes and additions to the evas gfx api -- and I'll deal with only
> gradients and a possible vgfx-objs api, leaving transforms (mos
Carsten wrote:
> On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>> As the subject states, let me make a (relatively) short summary of some
>> proposed changes and additions to the evas gfx api -- and I'll deal with only
>> gradients and a possible vgf
Carsten wrote:
> On Thu, 17 Jul 2008 05:58:24 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>> Ok, now for a proposed api for evas "vgfx objects" -- a very simple
>> one, but general enough to allow for the overwhelming majority of vgfx uses
>> (and certainly ones for most 'real
On Thu, 17 Jul 2008 05:58:24 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> Ok, now for a proposed api for evas "vgfx objects" -- a very simple
> one, but general enough to allow for the overwhelming majority of vgfx uses
> (and certainly ones for most 'real-time' use in evas).
>
>
On Thu, 17 Jul 2008 04:36:05 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> As the subject states, let me make a (relatively) short summary of some
> proposed changes and additions to the evas gfx api -- and I'll deal with only
> gradients and a possible vgfx-objs api, leaving transforms
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:
>
Peter 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);
>>
>>
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:
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_corn
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_rec
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
Just a couple of other remarks on these two (parts I, II) proposals:
Like the proposed gradient obj api function that sets an (affine)
"fill_transform",
there would be a similar one to set such on an image object:
void evas_object_image_fill_transform_set(obj, Evas_Transform *t);
Ok, now for a proposed api for evas "vgfx objects" -- a very simple one,
but
general enough to allow for the overwhelming majority of vgfx uses (and
certainly
ones for most 'real-time' use in evas).
Again, by evas "vgfx objects" we mean evas objects that can be "filled
and/or
stroke
As the subject states, let me make a (relatively) short summary of some
proposed changes and additions to the evas gfx api -- and I'll deal with only
gradients and a possible vgfx-objs api, leaving transforms (mostly) and filters
for later.
First, changes to the current gradient api. T
27 matches
Mail list logo
