Conventions
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.
Language
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))
return EET_ERROR_CANNOT_WRITE;
else
{
ef->data = NULL;
ef->count++;
}
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 configure.ac. 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.
