<PCLASS="western"ALIGN=CENTERSTYLE="margin-bottom: 0pc"><IMGSRC="enlightenment.png"NAME="Graphic1"ALIGN=LEFTWIDTH=320HEIGHT=320BORDER=0><FONTFACE="Bitstream Vera Sans"><FONTSIZE=5><B>Enlightenment</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-bottom: 0pc"><BR>
</P>
<PCLASS="western"ALIGN=CENTERSTYLE="margin-bottom: 0pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 6pt">Version
0.17.0 </FONT></FONT>
</P>
<PCLASS="western"STYLE="margin-bottom: 0pc"><BR>
</P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>What
is Enlightenment?</B></FONT></FONT>
</P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Enlightenment
is a Window Manager for X11. This is the latest incarnation of
code of the Enlightenment window manager (often referred to in
short as WM). This WM is built on the EFL (Enlightenment
Foundation Libraries) that have been worked on very hard over the
last few years. These libraries provide a sound base on which to
build the WM and related tools, utilities, and applications.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Right
now if you are just a "user" this code is NOT for you.
You're on your own. If you are a developer wanting to work on the
code - read on. But first we should take a break for some
history... </FONT></FONT>
</P>
</TD>
</TR>
</TABLE>
<HR>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>A
Brief History of Time... err Enlightenment</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">In
the past E has undergone 1 major rewrite since release DR
(Development Release) 0.1. This rewrite occurred for DR 0.14). DR
0.17 heralds another major rewrite. We have to be honest here. The
reason for this is the fact that we got lazy. Design went out the
window in favor of quick fixes and fast features. Too many people
worked on the code with too little care and attention to detail.
Large design mistakes were made, that to undo would be paramount to
half a rewrite. Patches were accepted without taking care to look at
them in detail, clean them or even reject them if not “well
done” enough for E's code. Thus the decision was made to fix
things once and for all and split things up, have well defined
interfaces (the EFL library API's) and clean and consistent code and
naming schemes. No it's not perfect - probably it will never be, but
we are trying. It is a massive improvement over anything
Enlightenment had before, and we are proud enough to probably say
it's some of the better API's and code of any available in the world
or used in any application or WM. It's not the best, but it's pretty
good. In doing this rewrite and split, we aim to not make those
mistakes again that happened before DR 0.17.0.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">With
Enlightenment and EFL's massive break-up into smaller sized chunks,
many users will complain about “how hard it is to install”
because there are so many libraries and inter-dependencies to handle.
We believe this is not our job, but the job of a package management
system to handle. We have documented the dependencies for people to
follow, but if anything, we aim to split things up more to make
maintenance, in the long term, an easier task. So in an effort to
avoid them, Here is a quick style and design guide for working on
this code. Please follow it, and if what you want to do doesn't fit
in, please discuss it first. Discuss your designs on the e-devel
(enlightemment-devel@lists.sourceforge.net) mailing list. Make your
code consistent and easy to follow - make it follow the style of the
rest in function naming, variable naming, access functions etc. Use
existing infrastructures - or extend them cleanly as needed. Just
because an infrastructure or system doesn't provide an accessor or
way of doing something does NOT mean you can't add it. Choose a clean
“correct” implementation over a nasty hack, all the time.
You get the idea. Now, on to the style guide.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Enlightenment
Stylin'</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Firstly
comes naming. All functions are name spaced. The EFL libraries begin
with library_something_something. It is object oriented naming so you
will have system_subsystem_subsystem_object_verb() as a name. For
example: e_config_load() or e_border_move() etc. All functions are
all lower-case with underscores between "words". All
functions that are accessed outside a file must have a prototype in
the file's header. All files have their code file (e_file.c) and a
header (e_file.h). The main "master" header (e.h) includes
all the smaller ones. All functions within that file are the same
name as the file. i.e. e_frog.c contains functions called
e_frog_something(). All internal functions only used within that file
should be declared as static and should begin with an underscore.
i.e. _e_frog_something(). All "local" globals (global to
that file only) should be declared static and beginning with _e_frog
just like functions. All static local functions should be at the end
of the file. All static function prototypes should be first at the
top of each file. All static local variables should come next, then
followed by the accessible functions. Any system that has "state"
should have an init and shutdown function. The init and shutdown
functions should be called from e_main.c during startup and shutdown
of the WM. It is encouraged that even systems that do not have state
have an init and shutdown call pair, just in case in future they will
gain state internally.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Any
system that returns objects (allocated structures) should probably
use the E_Object system as a parent. See examples on its use in the
code. E_Object provides a simple object wrapper with reference
counting, object pointer and type checking and safety that should,
runtime, trap a lot of potential problems and let the programmer know
about them. Use the object type checking macros for checking if an
object passed into a function as a parameter is a valid object.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Keep
to the indentation and spacing style thats there - it makes it easier
to read if all the code matches. All functions called as "callbacks"
should be called _e_system_cb_something. The "cb" denotes
that that function may get called by other code, maybe unpredictably,
at any time in response to an event, timer, or something mostly out
of the control of the program itself. Functions such as the free
function for an object aren't the same kind of callback, since they
are predictable and controllable, so they do not get "cb"
in their name.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">So
that's the quick rundown on basic coding style. More will likely be
added to this list, but the best way to put it all is "look at
what's there and follow the same style".</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Tree
Layout</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
E17 source tree is well structured, with a location for everything.
In the top-level directory you will find a src directory that is the
master directory for all the C source code for the WM and components.
You will also find a doc and data directories. The doc directory
contains all documentation (this document for example).</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
data directory contains all cross-platform data needed for the WM to
run as well as a basic default theme that it also needs to run.
Currently the default theme is not complete at all and is no
indication of Enlightenments final look when it is released. It is
only just enough to make it work and demonstrate an example of how to
make a theme. There is also other data used for things like low-level
error dialogs (used for example if the theme doesn't work) as well as
a default font and other system data such as data for the splash
screen displayed while Enlightenment starts up.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
src directory contains 3 main repositories of code. They are bin, lib
and modules. The bin directory contains all the source code for the