[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 kkapelon@freemail.gr 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