TD P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
P.western { font-size: 8pt }
P.cjk { font-family: "Bitstream Vera Sans"; font-size: 8pt }
A.western:link { font-size: 8pt }
@ -21,13 +27,13 @@
<COLWIDTH=256*>
<TR>
<TDWIDTH=100%VALIGN=TOP>
<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>
<PCLASS="western"ALIGN=CENTERSTYLE="margin-bottom: 0in"><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: 0in"><BR>
</P>
<PCLASS="western"ALIGN=CENTERSTYLE="margin-bottom: 0pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 6pt">Version
<PCLASS="western"ALIGN=CENTERSTYLE="margin-bottom: 0in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 6pt">Version
0.17.0 </FONT></FONT>
</P>
<PCLASS="western"STYLE="margin-bottom: 0pc"><BR>
<PCLASS="western"STYLE="margin-bottom: 0in"><BR>
</P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>What
is Enlightenment?</B></FONT></FONT>
@ -51,7 +57,7 @@
<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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
@ -60,20 +66,20 @@ 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
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: 0.79in"><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”
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
@ -87,12 +93,12 @@ 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>
way of doing something does NOT mean you can't or chouldn'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
Stylin' straight from the top of ma dome</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 0.79in"><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
@ -116,7 +122,7 @@ 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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
@ -124,7 +130,7 @@ 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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
@ -134,19 +140,19 @@ 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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
@ -156,7 +162,7 @@ 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
<PCLASS="western"STYLE="margin-left: 0.79in"><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
WM itself and any primary executables it uses during execution. The
@ -172,7 +178,7 @@ files etc. that are specific to that module. See further on for more
information on modules.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Design
Ethos</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">As
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">As
for design, Enlightenment doesn't strictly follow a conservative WM
design. It does some things quite differently, with the aim of
providing more features with simpler internal design to achieve more
@ -194,74 +200,73 @@ different resolutions very easily since it can control the virtual
root window, which is not normally possible to do with the real root
window.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Managers</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Managers
are the basic unit of window management. One Manager object is created
per root window to manage. For more people, even if they run Xinerama
across multiple screens, there is only 1 root window, and thus E17
will only ever have 1 Manager object. If the user runs traditional
Multihead there will be 1 root window per screen, that may be a
different size and color depth. E17 will create 1 Manager object per
screen in this situation. The Manager object handles redirection WM
specific events for the root window into the WM, thus effectively
being able to trap several kinds of events before a client gets to
perform them, thus enabling it to be a WM. A Manager object actually
creates a window the size of the root window it manages and covers
the root window up completely. Each Manager object may contain 1 or
more Container objects which in-turn create their own child windows
of the Manager window.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Managers
are the basic unit of window management. One Manager object is
created per root window to manage. For more people, even if they run
Xinerama across multiple screens, there is only 1 root window, and
thus E17 will only ever have 1 Manager object. If the user runs
traditional Multihead there will be 1 root window per screen, that
may be a different size and color depth. E17 will create 1 Manager
object per screen in this situation. The Manager object handles
redirection WM specific events for the root window into the WM, thus
effectively being able to trap several kinds of events before a
client gets to perform them, thus enabling it to be a WM. A Manager
object actually creates a window the size of the root window it
manages and covers the root window up completely. Each Manager object
may contain 1 or more Container objects which in-turn create their
own child windows of the Manager window.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Containers</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Container
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Container
objects create their own windows to CONTAIN managed window frames,
the desktop window (the desktop background is actually just a big
window that is always kept below all frame windows that contains a
canvas for displaying the desktop background and all desktop objects
such as a launcher bar, file icons, etc. etc.). The Container is
responsible for holding this together and also managing a list of
“obscuring” objects that fully obscure the desktop
canvas, so it can help optimize drawing to the desktop canvas by
avoiding to draw parts of the desktop background canvas that cannot
be seen at all. This list is also used to draw soft drop shadows on
the desktop canvas by the Dropshadow module. The Container object
managed the desktop background, which is actually a complete EDJE
object. This may seem strange as a simple JPEG or PNG or GIF may be
enough, but by using an EDJE object for the background, the desktop
wallpaper can be animated, react to events and input, scale
intelligently (not just “stretch” or “tile”),
where the desktop wallpaper designer can specify what elements of the
wallpaper scale, align, where and how, if they tile, overlay,
underlay each other, and how.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Currently
“obscuring” objects that fully obscure the desktop canvas, so it
can help optimize drawing to the desktop canvas by avoiding to draw
parts of the desktop background canvas that cannot be seen at all.
This list is also used to draw soft drop shadows on the desktop
canvas by the Dropshadow module. The Container object managed the
desktop background, which is actually a complete EDJE object. This
may seem strange as a simple JPEG or PNG or GIF may be enough, but by
using an EDJE object for the background, the desktop wallpaper can be
animated, react to events and input, scale intelligently (not just
“stretch” or “tile”), where the desktop wallpaper designer
can specify what elements of the wallpaper scale, align, where and
how, if they tile, overlay, underlay each other, and how.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Currently
the Container only responds to configuration change events to change
the background, which needs to be a path to an Edje .eet file that
contains a Edje group of the key “desktop/background”. It
will load this group, if present in the file, as the background. What
it needs is a configuration tool that can browse the filing system
and directories for .eet files that are like this, display thumbnails
and previews, allow a user to select a new background and maybe
specify if the background file should change between different
virtual desktops (which are currently not implemented), and also be
able to browse normal JPEG, PNG etc. files and “import”
them into a users wallpaper database (a directory of wallpaper .eet
files) and thus convert into a Edje .eet file, which now retains the
scaling, tiling and other preferences the user selected within the
file. The user can now give this file to others and it will retain
the same information, without them needing to know if the wallpaper
needs to tile as a pattern, stretch etc.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
contains a Edje group of the key “desktop/background”. It will
load this group, if present in the file, as the background. What it
needs is a configuration tool that can browse the filing system and
directories for .eet files that are like this, display thumbnails and
previews, allow a user to select a new background and maybe specify
if the background file should change between different virtual
desktops (which are currently not implemented), and also be able to
browse normal JPEG, PNG etc. files and “import” them into a users
wallpaper database (a directory of wallpaper .eet files) and thus
convert into a Edje .eet file, which now retains the scaling, tiling
and other preferences the user selected within the file. The user can
now give this file to others and it will retain the same information,
without them needing to know if the wallpaper needs to tile as a
pattern, stretch etc.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
desktop canvas is also shared by many modules that may display things
like battery meters, cpu load, launcher bars, drop shadows etc. on
the desktop background. The desktop canvas lets this be a bit more
organized than it would be with a “free for all” drawing
to the root window under more conservative WM's.</FONT></FONT></P>
organized than it would be with a “free for all” drawing to the
root window under more conservative WM's.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Borders</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Borders
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Borders
are the frame outside an application window that is controlled by the
WM and that holds the application window within, and allows users to
move, resize, shade, lower, close and otherwise control windows. This
is currently buggy and not very useful and needs work in combination
with the Manager system.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Menus</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Enlightenment
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Enlightenment
has its own Menu widget code to allow for highly themable menus that
match your WM's theme. These menus are intended to act as ways to
launch programs, select actions to perform with context sensitive
@ -274,20 +279,20 @@ delete and modify menu items while the item is still realized, and a
set of other things listed in the TODO list at the top of the
e_menu.c source file.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Modules</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Modules
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">Modules
are a new and powerful way to extend E17 by being able to load and
execute code during runtime that may be shipped with E17 or even
developed after installation as enhancements and additions. This
system still needs work in the configuration department, knowing what
modules to load and not load, if they are to be enabled once they are
loaded etc. It is possible to have “dormant” modules that
are loaded but not enabled. They will use memory and resources for
the module entry and the binary executable code loaded into memory,
but nothing else. An enabled module will also use resources for
objects, images, etc. etc.</FONT></FONT></P>
loaded etc. It is possible to have “dormant” modules that are
loaded but not enabled. They will use memory and resources for the
module entry and the binary executable code loaded into memory, but
nothing else. An enabled module will also use resources for objects,
images, etc. etc.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Dropshadow
Module</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
module demonstrates the Container shape system allowing a module to
monitor obscuring shapes in a container. This lets the module, in
this case, draw soft shadows under these obscuring shapes. It is a
@ -299,21 +304,21 @@ entirely from the blurring algorithm, and perhaps finding a way of
blurring using a Gaussian blur that is faster.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>IBar
Module</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
IBar module is a template for doing a “launcher panel” in
E17. It allows the user to manage a list of frequently used
applications to go into the IBar's panel. It is an attempt to unify
the configuration of “bars” in E17 so if a user changes
launcher bar modules, they can retain at least most of the basic
configuration, like what applications are in the bar, and so-on. The
IBar has some unique characteristics allowing a lot of applications
to be held in a small bar, by having it auto-scroll on mouse over to
the desired location in the list. It uses the Application interface
to fetch a list of applications and monitor this list for changes on
disk. The IBar also allows itself to be resized and dragged around
the edges of the screen, set to fill a edge, auto-size to fit its
contents, or be a fixed size.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">It
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">The
IBar module is a template for doing a “launcher panel” in E17. It
allows the user to manage a list of frequently used applications to
go into the IBar's panel. It is an attempt to unify the configuration
of “bars” in E17 so if a user changes launcher bar modules, they
can retain at least most of the basic configuration, like what
applications are in the bar, and so-on. The IBar has some unique
characteristics allowing a lot of applications to be held in a small
bar, by having it auto-scroll on mouse over to the desired location
in the list. It uses the Application interface to fetch a list of
applications and monitor this list for changes on disk. The IBar also
allows itself to be resized and dragged around the edges of the
screen, set to fill a edge, auto-size to fit its contents, or be a
fixed size.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">It
needs work to be done on auto hide and auto show, so on an auto show
it could signal other parts of E17, for example, to slide all windows
out of the way, or other such features. It needs work to display
@ -324,12 +329,12 @@ work is to support subdirectories in the bar's application list. How
best to do this is still up in the air. For now this isn't supported.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Test
Module</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
is just a test module for playing with new module features. It will
not make its way into a final E17 release, but can be used as a bare
skeleton for building a new module.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>Applications</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">This
subsystem is responsible for being able to list applications held in
E17 specific application directories. This system can inform other
parts of E17 and modules of changes, such as an application being
@ -338,7 +343,7 @@ in a directory changing, an application being executed or displaying
its window, or finishing execution. It can share the application
lists between multiple systems to save RAM and CPU and I/O in loading
them multiple times.</FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">It
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">It
may be of surprise to find E17 is not loading the XML, .desktop
entries etc. etc. than KDE and GNOME use. In all honesty that system
is a little overcomplicated and hard to keep up with. It also is not
@ -351,7 +356,7 @@ create such files FROM existing system databases of applications and
monitor these for changes, reflecting those changes in Enlightenments
application directories.</FONT></FONT></P>
<PCLASS="western"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt"><B>IPC</B></FONT></FONT></P>
<PCLASS="western"STYLE="margin-left: 4.73pc"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">IPC
<PCLASS="western"STYLE="margin-left: 0.79in"><FONTFACE="Bitstream Vera Sans"><FONTSIZE=1STYLE="font-size: 8pt">IPC
(inter process communication) is provided in E17 as a mechanism for
another application to send commands and requests to Enlightenment
and receive responses with information. This mechanism is intended to
@ -362,90 +367,89 @@ but will accept clients connecting. Many commands need to be
implemented here, such as being able to ask E17 to load or unload a
