Carsten wrote:
> On Sat, 19 Jul 2008 05:56:53 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>
>> Or rather, what to do with "edc" and its use for representing gfx
>> components in both edje and evolve... that's the real question here.
>>
>> Right now, evolve has no direct 'gfx' representations other than via
>> edje/edc, and the latter is limited to what has been available in evas so
>> far.
>> Edje/edc itself deals mostly with defining "groups" -- which are a kind of
>> 'template' for creating stateful, compound evas objs (certain smart objs)
>> from
>> basic gfx components (ie. the "parts").
>> But with an extended set of gfx capabilities for evas (vgfx stuff,
>> transforms, masks, filters, ...), one can *begin* looking into extending the
>> descriptions of such parts so that such new gfx aspects can be represented
>> via edc and/or scripting.
>>
>
> yup. indeed. and with edje.. i'm open to this. for example - if we have enough
> vgfx to do full svg (and scale it realtime) then i see no problem adding
> proper
> svg support so u can include svg's just like you do png/jpg etc.
>
>
You don't have to include "svg" support right away - that would be one
possible addition, and would go along with a relevant "svg" evas object as
discussed in the other thread on vgfx stuff.. ie. likely best done via setting
a file/group on such an svg obj. It might be fast or slow depending on the
rendering implementation, but it would be there if one really wants it.
But that's not the only thing one can do. One can still add support for
vgfx aspects that relevant evas objects might support - ie. stroke and/or fill
of rects, lines,polys, possibly text, paths (if/when those are defined), etc.
For example, let's simply consider rectangle objects (as they're already
supported by edje), and let's say one has added "rounded/beveled corners"
support
to those in evas, and let's say one has also added support (in evas) for
stroking/filling them with grads or images, and let's say that it's via
the evas api I proposed.
How then would you go about representing these new properties for rects
in edje/edc (and/or via scripting) so you can take advantage of that?
This has been done already by such things as svg, mxml, and xaml. One just
needs to sit down and give it try with the edje/edc format (and implement it
in edje). It's not hard to come up with an equivalent edc description for
supporting those things for rects, one could even take a look at what the
above mentioned formats do and pretty much do the same.
> this has already been discussed with respect to native video format handling
> for evas - getting 2 codecs in place that:
>
> 1. allow for very efficient lossless encoding AND fast decode (beter than
> encoding X full images).
> 2. allow for lossy encoding (mpeg/mpeg4/h263/624/theora - whatever but use
> one)
> that can also provide an alpha channel.
>
> so open for improving it.
>
>
>> More could also be done in evolve/edc to introduce *canvas*
>> presentations, by which I mean something like what Flash/mxml and
>> Silverlight/xaml (and svg) allow developers/designers to define.
>>
>
> i've looked at flash before - in detail. i know where it stands relative to
> edje :) i get where you are coming from - and yes - we should/need to/want to
> expand to support this kind of stuff. one of the steps was more extensive
> scripting - ie more embryo - or look at lua.
>
>
>> In fact, I'd encourage those interested in gfx matters to take a look
>> at those two formats (and the apis behind the relevant libs) and see what
>> can be learned from them in terms of expressive capabilities so that one can
>> *begin* getting ideas as to what could also be done in both edje/edc and
>> evolve/edc (and possibly with scripting and/or C as well).
>>
>
> indeed - agree. and i have. i've kept mental notes for edje for a while...
> that
> is one reason for the video codec and extended scripting. basically from
> flash/swf. if we have better vgfx in evas we can consider svg support too...
> and more. i'd like to extend the tweening and animation stuff - add spline
> curves, paths, containers.. and more. there is room to improve. it just takes
> time and effort. one step at a time! :)
>
Right. And note that there's already an animation lib "etch" that
covers much of this stuff at a level that could be used by edje and anyone
else. But there are things here that would also best be done via evolve/edc
rather than edje/edc (and evolve/edc though only supported by etk right now,
could likely be implemented via ewl if desired).
This would correspond to 'widget-level' descriptions as is done say by
Flex (rather than Flash) and in WPF (rather than Silverlight). Actually,
evolve/edc could be rather complete if desired - representing all that edje/
edc does at a higher level, and more.
One can define 'gfx-widgets' (implemented as imports of evas gfx prims),
and their layout on a canvas widget for example, and define animations of
properties. One can even define a new widget type, call it a "group" widget,
which would be like edje's groups but with other widgets as 'parts' (ie. child
widget members of the group container), and such.
The higher level of abstraction that the toolkits offer for defining
container and/or constraint widgets, can be combined with primitive gfx-widgets
as well, thus offering near everything in one single api/object-model. It's
not really necessary to drop in-and-out of widgets vs evas as is now done,
the toolkits could do it all via suitable widget types, and it could all be
represented via evolve/edc rather than edje/edc.
Edje/edc itself though can also do and represent more as we've mentioned,
it's really a matter of what's a preferred api/event/object-model and whether
one wants to represent some of this via something like 'edc'...
In any case, regardless of where/how this is done, ultimately I think a
good
gui tool for building with such things is what'll really be useful, and more
people
who are able and interested in taking all these 'steps' are needed.
____________________________________________________________
Explore all of Europe's beauty! Click now for great vacation packages!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nKHMT4DHisjZvrS5ZGUOrp16GF0kF6PNyF1qtcanHDXcwU0/
-------------------------------------------------------------------------
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