Hello all,

Users of recent SVN may notice recent breakages around things that use Efreet and FreeDesktop.org (XDG) standards.

The breaks were introduced after changeset:46726 "Eet cache for efreet desktop". The commit title says it all, Sebastian is speeding up our previously quite slow and memory heavy code with Eet-powered cache to be shared amongst multiple processes.

Efreet was the slowest bit in whole E platform, a real pity. But Sebastian invested quite of time to have a third party process to parse all ".desktop" files, generating an optimized blob stored into Eet.

Eet data structures will be quite fast and strings will be only pointers to memory if using functions like eet_eina_file_data_descriptor_class_set(). This is quite good for both load time performance and runtime memory consumption, as no strings need to be allocated (so less Virtual Memory pressure), the pages are shared among different processes and can be sent back to file system, helping applications that actually need memory (less OOM cases). This is quite easy to use, and highly recommended for applications, even when you do not share with other processes.

So why do we have breakages, you might wonder? The crashes are due the way Efreet API was exposed and used. Instead of providing opaque Efreet_Destop structures with getters and setters to fields, it was exposed as direct access struct with public members, making cases such as the following common:

void name_changed(Efreet_Desktop *desk, const char *name)
{
     free(desk->name); /* crash if name is a pointer to mmap()ed file region! */
     desk->name = strdup(name);
}

This is spread all over E17, but major user is desktop file editor. Other parts may do it as well, such as changing the border or ibar/ibox icons.

These issues should be fixed soon. If you'd like to help with patches, just mail them to enlightenment-devel mail list. If you can't avoid these crashes, be sure to checkout the old Efreet meanwhile:

svn checkout -r 46726 http://svn.enlightenment.org/svn/e/trunk/efreet

Sorry about the inconvenience.

Every free software project aims to bring more developers. However once we get people interested, how are they received, how to proceed and get started on E17/EFL development? This topic is becoming more and more common as E17 becomes more "ready" for it's final release and also EFL is being used in lots of devices, specially mobile devices like phones, pdas, ebook readers and so on.

E Community is trying to solve this with documentation, template generators and now screencasts!

Documentation

We now have daily updated API documentation generated from Doxygen, these are at http://www.enlightenment.org/p.php?p=docs (click "Docs" in E website). Rasterman started Elementary with great docs from start, Eina is a good example as well, with tutorials and such, ProFUSION also helped a bit with review and documentation patch requested by clients.

Template Generators

We had E-MODULES-EXTRA/skel for a long time, but that was not enough. Then elementary-generator was created with helper script and even nice GUI to create all the boring parts: makefiles, configure.ac, license file, C source file with gettext support and even Elementary's quicklaunch feature. The generator itself is easily extensible, all one need is to add files to some directories (description, screenshot and source).

 Elive guys created a similar tool "emodule-creator"  deb, which is handy to start writing E17 modules with minimal effort.

Screencast

As Thanatermesis put very well in his mail:

Now there's only one thing needed to motivate new ppl to make e17 modules, something "to see".

The ppl dont' read, not much ppl at least... the ppl are lazy to download something and to try it, the best is a tutorial explaining the creation of an e17 module, but finally, what's better for that than a video that shows how we can build and customize an e17 module in less than 10 minutes ? :)

and then announced his nice screencast:  http://www.youtube.com/watch?v=abNsVyYTSkU

I have looked a bit at the OpenSolaris port. Though its compiler is a lot more strict than gcc, Eina, Eet, Evas and Expedite can be compiled. Expedite seems to run too.

The instructions on how to compile the code on that platform can be found here.

I still have problems with the compilation of Ecore and Embryo, but I'm investigating that. Any help is welcome, of course.

Please help with testing and packaging it for your distribution, so we can get wider testing.

• Svn revision to use: 41533.
• Snapshot tarballs:  http://download.enlightenment.org/snapshots/2009-06-14/
• Release (eet) tarballs:  http://download.enlightenment.org/releases/
• Release Plan
• Release Schedule
•  Raster's announcement

Next snapshot is due Monday, September 7th. We plan to skip August to have time to merge Google Summer of Code projects and do aggressive hacking, but maybe we can find some room to another release. If things go well this will be the "alpha" snapshot and then we move on to beta, release candidates and final release! But we need to finish features and improve overall quality, get your editors and hack!

The installers (with and without debug symbols) have been uploaded. They are based on revision 41042 of the svn repository. They can be found in the binary packages page.

The installed EFL are Evil, Eina, Eet, Evas, Ecore, Embryo, Edje, Elementary and Ewl. Expedite, as well as all needed dependencies, are also installed.

Development files (import and static libraries, header files, .pc files) can be installed if they are selected.

André Pedralho just  announced at enlightenment-devel mail list that his team at INdT released Webkit-EFL 0.1, the first release of this integration project.

Webkit-EFL brings together the power of webkit rendering engine to EFL applications, integrating with ecore main loop, evas canvas and input system as well as themes using edje. Rendering is done using cairo and networking uses curl, so shares base components with other webkit ports as GTK.

Similarly to Edje and Elementary, everything is exposed to developers as Evas_Object, so you can swallow, clip and go as crazy as you would with any other object. In fact, it's double-buffered using an internal image object. That is good since you can resize, clip, fade and move without paying re-render price, but be aware that it can add some overhead for pages with heavy animations (nothing comes for free, sorry ;-))

The code was developed mainly by  INdT/Manaus. It is hosted at gitorious so it's easy to clone and contribute, as well as rebase with upstream webkit, which they do on a regular basis.

We have a sample browser using webkit-efl in svn, it's called Eve and lives under PROTO/eve, please join development so we can have great integration of Enlightenment and web technologies, rendering web content inside our apps.

For more information see André's co-worker page:  http://tonikitoo.blogspot.com/2009/06/webkitefl-01-released.html

Hi all,

Thanks to huge effort by various contributors we're proud to provide a stable development snapshot of EFL and a new release of Eet library. Please help with testing and packaging it for your distribution, so we can get wider testing.

• Svn revision to use: 41040.
• Snapshot tarballs:  http://download.enlightenment.org/snapshots/2009-06-14/
• Release (eet) tarballs:  http://download.enlightenment.org/releases/
• Release Plan
• Release Schedule
•  Raster's announcement

Next snapshot is due Monday, July 27th.

Hello all,

If you follow Release you will notice that more and more items are being strike out in the past months due work of many individuals, we'd like to thank them all. Among contributors we can even find out nice examples like Luca De Marini that is not a programmer but fund/help the work of Sergey P. Semernin to help finish that list.

I'd like to ask more people to step in and help, either with code directly of following Luca's example and finding a developer to do so (no need to pay, you can find a friend willing to do work). If you are willing to help but have no deep knowledge of the project, we can aid you with such tasks. Lots of them just require basic C skills, like converting Ecore/Evas? data types usage to Eina (in Ecore, E_DBus, efreet, ...). We also need developers with optimizations and profiling skills to help with Efreet (not much to think, it's all known, just need manpower to implement).

Last but not least we need bug reports, and bug report reviewing! The last part is important, for example we had a bug listed as "efm will not work with other fm's drag&drop" but it does, so go there and comment on bugs. Not all developers spend lots of time on Trac (shame on me!), so if you have a bug that is there for some time without any comments, don't be afraid and post it here (e-devel or e-users), or talk with us at IRC (#edevelop or #e), maybe you can have your problems fixed by the end of the day ;-)

That's it, let's rock!