On Friday 07 April 2006 08:25, David Seikel wrote: > On Fri, 7 Apr 2006 14:20:15 +0300 [EMAIL PROTECTED] wrote: > > I have seen the developer docs for Enlightenment. > > I know that they are behind the latest code and I am not going > > to moan about it. Programmers always like to write code more than > > docs. > > > > However there is not any high level documentation. > > I mean documentation which describes the concepts of efl. > > Most people think (I may be mistaken) that efl is another > > toolkit like gtk+ or qt. Of course this is not true. > > > > The most important points are in my opinion the fact that evas > > knows the "state" of the canvas and the fact that making an > > application edje themable completely separates logic (code) with > > looks (theme). > > > > I think that this kind of documentation will draw interested > > programmers to efl who at the moment dismiss it, thinking that they > > should stick with gtk+/qt. > > > > Is there any interest about this? > > I am asking because I would like to start this kind of documentation. > > I would be very interested in this sort of documentation. I would also > be interested in contributing what I know. Have you seen the edje book > and similar things? > > The big problem is the that things are still changing too much for any > big picture stuff to stay relevant for long. The big picture for how > modules work for instance, it's gonna undergo a radical change any > minute now. So any high level documentation will have to track some > rapidly moving targets.
I had been planning to include a lot of "efl design tips" along these lines when I started my tutorial series (that never got anywhere). (They're up at: http://rephorm.com/pages/tutorials/evas/toc -- and yes, i realize the page is a bit screwy when the content is too short) I think the major features of the library set are fixed enough that this sort of documentation wouldn't be that difficult to maintain. Some concepts that need mentioning: * As you mentioned, evas is a canvas, so it keeps state and optimizes drawing for you. You simply describe the objects in your scene. * EFL apps are (usually) single threaded. Usually, one can simply update state flags on events and delay any 'heavy lifting' to idle time (Ecore_Idlers). [ e17 is like this for the most part. express is another example of this pattern. ] Along with this point, blocking functions (e.g. sleep()) are generally not that useful (I've seen sleep() in particular come up in newbie question often). * When using edje to separate the gui from the app there's a bit of a tradeoff between total separation / theme flexibility and ease of theming. Small apps like Elicit work well as "all done in edje" with only a few layout smart objects (esmart_containers). Most larger apps will need a good set of smart objects (widgets / containers) to keep them from becoming impossibly complex to theme. ... plus lots more ... I would be happy to help out with something like this, but don't have the time to lead / manage anything at the moment (and would definitely rather spend most of what time I do have coding) . I'm not sure who would be best for the job. Someone with enough EFL coding experience to understand the intended design , but who also has free time and doesn't feel like coding? Not sure such a beast exists... :) -- rephorm ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
