On Sun, 3 Aug 2008 16:49:05 +0200 Raoul <[EMAIL PROTECTED]> babbled:

> Here is my feedback about Edje.

aaah raoul! - btw.. calaos is fantastic - what you've done is great and you
ahve heavily used efl... so it's one of the prime examples here and your input
is very important (as is that of any other major users of efl, in addition to
what we have in CVS).

> We used a lot of embryo code in the calaos project. Most of the time it is 
> just to set/get some simple vars for more control on "states" of an object. 
> This is ok, works great, and embryo is designed to do that. About the swith 
> to another scripting language, i will just say 2 things. This is ok for me, i 
> will do the conversion in my edj (perhaps i don't have anything to do, 
> because embryo and lua syntax are close). It would not be a lot of work for 
> me. Lua would be a good choice, it's a very small VM, and it will run 
> smoothly on embedded devices.

ok. so you would "live" with a transition over.

> But, I think there are more important issues with edje at this time. Writing 
> edc using macros are a real pain and a waste of time. Macros are hard to 
> write, hard to debug, hard to maintain and unreadable. We need a better way 
> to write generic object (edje script only?).

exactly! this was what was prompting my exploration into alternatives. i
started writing the script_only code for edje... it works... but it uses
embryo. as i was doing it i realised just how heavy the calls going into and
out of the embryo vm were - i made changes to make that lighter, but then
realised, to make bindings easy... i was re-creating a lot of glue (converting
pointers to object id's back and forth for example) and being able to have
dynamic datatypes without going thru the heavy get/set api. (eg just an array u
can alloc of object's or a list etc.) that is native to the language. this is
where embryo stumbles. it has no heap of its own to alloc to - so all allocs
happen via a binding... even for simple temporary data for just doing
intermediate work... and it was looking really cumbersome to do, so i was
beginning to think it may be a good idea to look further into other
solutions... thus the lua thing came up. before embryo was used, lua was a
close second - and ferite was definitely on the list too.

> Edje is also missing some more complex objects like lists. For now, any lists 
> have to be done in the C side, it "freezes" a bit the theming capabilities. 
> Having the possibilitie to extend edje by exporting a smart-object (list or 
> any super-cool-smart-object) with its properties and capabilities to edje 
> would be awsome.

yup. this is also planned to be added. layout objects in edje where you can
just pack/unpack multiple children and the layout object lays them out in a
vertical/horizontal list, maybe a horizontal list with line-wrap, and for that
matter, all sorts of other arrangements. the reason edje didn't get this on day
0 was that i wanted these layouts to be able to do all sorts of fancy things -
if designers wanted to - eg a spiral, a curved line of items that resize and
fade in and how as they walk along the list etc. the problem was in how to
expose such a layout engine to a designer and make it easy to use yet powerful.

> For example, in the application code, you tell edje to load a LIST 
> smart-object with some properties, and then edje can use it like a standard 
> parts in the edc. In the part definition, you can change the properties of 
> the LIST, like enable/disable kinetic scrolling, horizontal/vertical 
> scrolling, ...
> 
> Such a feature could really help designers to be more productive in writing 
> edc, and give them much more power.

yup.

> As I said, for now writing edc is a painfull task.
> 
> -- 
> Raoul Hecky
> Calaos
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    [EMAIL PROTECTED]


-------------------------------------------------------------------------
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

Reply via email to