All our source code is available from our SVN source repository at all times. If we actually are moving seriously on a piece of code, it will make its way to our download page. For something supported, look there. If you want to help with development or are just hyper-curious and want to see what's in our workshop, then you will want to browse through our SVN repository. Alternatively, you will want to check it out.

Our SVN repository is not small. There's currently over 1.5 million lines of C source code alone in there. Along with some other languages. A full local checkout will use about 1.2 GB of local disk space. To check it out you will need subversion. Most Linux distributions come with packages for them. For other operating systems your luck may vary. There is Tortoise SVN for windows, and OSX users can just use regular subversion like their Linux counterparts. To check out all of SVN just use:

svn co

(You can also use https instead of http if you want to use SSL encryption)

You can also use git (with git-svn) if you want to maintain lots of local branches, code and features and generate patches and so on. You can do this with:

git svn clone

You can alternatively download the git-svn tars from here and use them instead; This alternative is significantly faster.

To update the code in your tree (pull in changes from our master tree), just use:

svn update

Or for git use:

git svn rebase

If you have made changes you'd like to share, you can generate a patch file from your changes with:

svn diff

Or with git

git diff

Please read the appropriate manuals for your chosen revisioning system so you know how to use it effectively.

Once you become an enlightenment developer, you will possibly get SVN commit access. This means you can not just fetch the code and generate patches, but you can also directly put changes into SVN (commit them). All changes are watched and broadcast on our SVN Commits List as they happen. To gain a copy of the tree as a developer with commit access you will want to check out the tree with one of the following commands (depending on if you want to use SVN directly, or SVN via git), where USER is your assigned username:

svn co svn+ssh://

git svn clone svn+ssh://

You can also use the git svn tars with a developer access, you just need to run the conversion script as follows:

  for example:
  ./ tasn evas

You can also use our git mirror server at:

git clone git://

Our SVN tree is divided up and categorized. The trunk directory is where all the main development happens. Inside this directory most maintained source lives in the base. We divided off bindings for other languages off into the BINDINGS directory. The E-MODULES-EXTRA contains a whole bunch of modules for enlightenment that may or may not work - try at your own risk. PROTO contains prototype applications. TMP is scratch space for projects yet to be categorized or found a home in the tree. We could go on telling you about the tree, but it's best to just look around and see. Just keep in mind that this tree is our "workshop" and parts of it may be in better condition than others and may or may not be usable. If you look here it is assumed you have a good technical grasp on things and can work out what is and isn't relevant or being worked on or going to be released any time soon.


Almost all our project are C based (with some C++). They almost all use autoconf, automake, libtool etc. (autotools) and any such source tree will ship with an script. This is where it all begins.

To build a library or application simply start by running the script (and pass in a --prefix="/where/to/install" option if you wish something other than the default /usr/local install location). The script will run configure for you, passing in any parameters provided to it to configure. After this you should be able to do the usual make and make install (as root if you install in a root owned location). So a quick recipe for building anything would be:

./ && make && sudo make install

You will definitely want the following installed to build EFL and E (exact package names may vary from system to system):

  • subversion
  • gcc
  • autoconf 2.59 or better
  • automake 1.10 or better
  • libtool
  • make (gnu make)
  • gettext
  • libpam dev headers
  • libfreetype dev headers
  • libpng dev headers
  • libjpeg dev headers
  • zlib dev headers
  • libdbus dev headers
  • liblua 5.1 or better dev headers
  • libx11 dev headers
  • libxcursor dev headers
  • libxrender dev headers
  • libxrandr dev headers
  • libxfixes dev headers
  • libxdamage dev headers
  • libxcomposite dev headers
  • libxss dev headers
  • libxp dev headers
  • libxext dev headers
  • libxinerama dev headers
  • libxkbfile dev headers
  • libxtst dev headers

Some extra optional packages for support of bonus features that you might want installed also are (there are even more optionally supported libraries than these, but these are the main/recommended set):

  • libtiff dev headers (tiff loading support in evas)
  • librsvg dev headers (svg loading support in evas)
  • libgif dev headers (gif loading support in evas)
  • libungif dev headers (gif loading support in evas *1)
  • libcurl dev headers (http download/fetch support in ecore *2)
  • libc-ares dev headers (async DNS lookup support in ecore)
  • libgnutls dev headers (signed eet files, secure tcp connection support for ecore)
  • libasound2 dev headers (alsa sound card support in E17 mixer module)
  • libudev dev headers (to build eeze for udev support)
  • mesa-common dev headers (OpenGL2.0 or OpenGL-ES2.0 support in evas)
  • libspectre dev headers (Postscript Loading support in evas_generic_loaders)
  • libpoppler dev headers (PDF loading support in evas_generic_loaders)
  • libraw dev headers (RAW loading support in evas_generic_loaders)
  • libgstreamer dev headers (Video file loading support in evas_generic_loaders)

*1. Due to a patent issue in GIF compression, libungif was created to work around this, but the patent has since expired so it is not needed anymore.
*2. Please ensure your system libcurl is compiled with c-ares support to avoid blocking DNS lookups when doing http transactions.

Enlightenment does lots of runtime support checks. If you want network management support you will want to install the connman daemon so you can connect to wireless and wired networks. You will need to load the Connection Manager module. For Bluetooth support you may want bluez installed and load the Bluetooth Manager module. You may want ophono installed, and load the Mobile Modems Manager to get support for wireless modems like 3G UMTS. You may want hal installed if you don't have modern udev support on your system. Enlightenment will discover these services via DBUS at runtime. Note that Enlightenment can run without DBUS, but it will be severely limited in functionality and it is never tested in this scenario.

Also note that for many other libraries and applications you may want or need other dependencies. These will vary from project to project. For example - emotion will require either gstreamer or libxine libraries and development headers to build.

The following handy script will also give you an insight as to how to compile things and in what order:

set -e
eina eet evas evas_generic_loaders ecore embryo edje e_dbus efreet eeze e"
svn co $SVN
for PROJ in $PROJECTS; do
  cd trunk/$PROJ
  make clean distclean || true
  ./ $OPT
  sudo make install
  cd ../..
  sudo ldconfig


We follow many conventions in order to work as a team despite the fact that we are spread around the world, in many different timezones, speak many languages, run multiple operating systems and have divergent goals. These conventions cover how we speak, communicate, what our code looks like, what our source trees look like and more. These conventions help our many disparate libraries at least look somewhat alike and makes maintenance, development and troubleshooting much easier. It also helps with an introduction to Enlightenment and EFL as the rules you learn in one place allow you to quickly discover what you need in another unfamiliar location, as it follows the same conventions.


Our primary language is English. For better or worse it is the one language most of us know better than any other. All documentation, comments and discussion should be in English. It doesn't need to be perfect. It needs to be understandable. So when you write code comments, discuss anything on IRC, in E-Mail or otherwise, please keep it in English.

Coding Style

Our golden rule of coding - FOLLOW THE CODING STYLE ALREADY THERE. That means that if you work on code that already exists, keep to the spacing, indenting, variable and function naming style, etc. that already exists. Don't go changing it mid-file or mid-project. It is even better if you use the same formatting for new projects that has already been used on others. It means the code is easier to read and maintain.

static Eet_File_Node *
_eet_node_find(Eet_File   *ef,
               const char *name)
  Eet_File_Node *efn;
  int hash = _eet_hash_gen(name, ef->dir->size);
  for (efn = ef->dir->nodes[hash]; efn; efn = efn->next)
      if (_eet_match(efn->name, name)) return efn;
      else break;
  return NULL;

EAPI Eet_Error
eet_sync(Eet_File *ef)
  Eet_Error ret;

  if (_eet_check(ef)) return EET_ERROR_BAD;
  if ((ef->mode != EET_MODE_WRITE) &&
      (ef->mode != EET_MODE_READ_WRITE))
      ef->data = NULL;
  ret = eet_flush(ef);
  return ret;

Source Trees

We use "autotools" as our build setup. For better or worse this is the predominant "standard" when it comes to build systems in the open source world. It's the devil we know and changing it is an uphill battle that may not actually end up in a better position than where we started. So it's staying, for now.

The configure template file is This determines the package name, version, what it checks for in dependencies and what Makefiles are to be output in what directories. If configure has extra macros we place them inside the m4 directory. Here you will find extra non-default autotools macros for checking of dependencies etc.

Source is structured with source code being in the src directory tree. This in turn is split up into directories like bin (that produces binary executables), lib (that produces shared libraries for others to link to), and modules (that produces module shared objects that the binaries or libraries may dynamically load at runtime to add new features).

The documentation templates and build happens in the doc directory and uses the same template style for html etc. so our documentation looks consistent.

In the data directory you will find possibly many things, but mostly data files that get installed and then needed at runtime such as icons, desktop files, theme files (edj) and so on. This will normally be broken up into sub directories here too.

Some projects have a config directory in which a set of default configuration files are set up and installed by default, maybe split into profiles and more.

In some projects there is even a win32 directory for files related to building that project on windows.

Licenses & Copyright

By default we stick to open source licenses. GPL, LGPL, BSD and so on. The person who starts any project calls the shots on its initial license and it is assumed all people contributing to it do so under the terms of that license. We also respect the licenses of others and their works, so we won't be accepting code that we know is already under an incompatible license. All projects should contain a COPYING file in the base directory of that project that covers all files in that project (unless otherwise stated).

If you want your name listed as an author of a project when you contribute code, PLEASE remember to include your name and E-Mail address as a patch to the AUTHORS file. This way you will have the correct name and contact details listed. All members of the AUTHORS file share copyright over the code they contribute to. So remember to include this change to AUTHORS for the first patch or commit you provide to make sure your name is immortalized in blinking lights in the AUTHORS file.

If you want to begin work on a a feature - something that isn't just a small trivial fix or feature, please discuss it on our mailing lists or IRC channels or both. Generally try and find the person in charge of that component, but if you can't, a broadcast to the devel list should find them. At this point you should discuss your idea and plans. This is where you can find out if someone else is already doing it, if it's a good idea or not, if it can be done better, how it should be done etc. Once you get agreement, you will know what to do next. Doing work and then just dumping it on developers as a surprise generally doesn't get a positive response. It was unexpected and often quite large. If you send small patches and changes over many days or weeks, as opposed to wait weeks or even months then send a single massive patch, you will get much better response. Big patches discourage review as time to review it is large and most developers just don't have such large blocks of time. Lots of smaller steps always works better.

Join us

If you join us you'll be welcomed into a community of developers and users who like to do cool things and actually make them happen. If you join you will not only be able to hang out with us (well you can anyway), you'll actually start to have a say in how Enlightenment and EFL develop, if not actually get some control. It also reduces a massive amount of work involved in maintaining forks as your work becomes mainline and gets shared, tested and maintained by a wider audience earlier, not to mention it likely becomes much better quality. If you are not into doing code, maybe you can help in other ways like with advertising and publicity, documentation and packaging, if not just regular bug reporting.

To report a bug please see the contact page. To submit initial patches for code, please send them to the mailing list after discussions have taken place. Keep patches small and send them, often as you work. Small patches get reviewed quickly. Large patches get delayed or sometimes ignored or lost. Make sure that any patch at least compiles and doesn't break an existing functionality (so make the changes enableable at compile or runtime as part of the patch if it does intersect with existing functionality). You will get feedback on your patches and may be asked to make changes before inclusion. Also remember to respect the formatting and conventions of the existing code as it gets a bit tedious asking for basic changes like naming, spacing and general style. We'd rather focus on the actual algorithms and features involved.

If you want developer access (SVN commit access) first you will need an existing developer to approve that. Generally any senior or long time developer can do it - new ones can too but will probably defer the OK decision to a senior developer first. To gain access we need you to provide a few files. The kind of files you find like this developer.

The info.txt file provides general information about you. Please fill one in with relevant information needed, with your Login being the developer login name you'd like, as well as other important fields. If you are new the Managing and Contributing fields may be empty, as well as Group, but please provide everything else including your location in the world as well as actual Geographic data.

The is your SSH public key. You will find this in your ~/.ssh directory. If you don't have one yet, you can generate one with:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

for example. You should read the SSH manuals for more information if you need it. This SSH key will give you access to SVN so you can check out and commit code, with all traffic between you and being encrypted.

As an addition we also ask you to provide some photos/images/icons of yourself so we can put a face to a name. Take a look at the example ones in the above developer directory. Provide images of the exact same size in pixels, with the icon-map.png file having an arrow at the bottom pointing down. This image is used on our world developer map.

If you can't write code, you can always help by writing documentation or articles or blogs. Contributing content to our wiki site that may help other users is always useful. We also always can do with artwork and graphics people. People who do artwork would be able to get developer access as they will need access to the source trees so they can put their artwork in there anyway. We also can always do with people helping translate things. We use gettext like most open source software, so it's as simple as providing us with new or updated .PO files. We even have a dedicated mailing list for just this purpose.

Otherwise, debugging is also something that is always needed. No code is perfect. It's written by humans. But bugs need to be fixed and to help you help us find the bugs we don't see, but you do, see our debugging page that lets you know how to begin to find bugs and provide useful feedback.