[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Efl High level documentation
On Friday 07 April 2006 08:25, David Seikel wrote:
> On Fri, 7 Apr 2006 14:20:15 +0300 email@example.com 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
* 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
* 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
... 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... :)