From: Carsten H. (T. R. <ra...@ra...> - 2008-08-03 22:06:15
|
On Sun, 3 Aug 2008 16:49:05 +0200 Raoul <rao...@gm...> 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) ra...@ra... |