Official Announcements

Enlightenment DR 0.19.0 Release

The E19 Release Cycle has concluded. Thanks to everyone who helped along the way.

Major changes since the last stable release include:


  • greatly improved wayland support
    • E_WL_FORCE environment variable for forcing output types
  • e_uuid_store: Add infrastructure to store window/surface properties.
  • Add a tiling profile.
  • per-screen desklock logo visibility config
  • Tiling: Merge the tiling module rework..
  • check udisks1 DevicePresentationHide flag
  • ACTIVATE_EXCLUDE window active hint policy
  • show video resolution in filepreview widget
  • add fileman option to clamp video size for video previews
  • handle xrandr backlight using a single, accurate handler
  • blanking options for wakeup on events (urgent + notify)
  • packagekit module for package manager integration
  • ibar now optionaly triggers its menu on mouse in
  • selective redirection toggling
  • new focus option "raise on revert focus"
  • add PIN-style desklock for lokker module
  • make desklock hookable, break out current desklock into module, move pam stuff to separate file
  • revive personal desklock passwords
  • allow moveresize visuals to be replaced
  • allow desk flip animations to be handled completely externally
  • E16-style live pager returns!
  • comp config is no longer a module
  • E_FIRST_FRAME env variable
  • new compositor API
  • add E_MODULE_SRC_PATH for setting current module src path without needing to install modules
  • use non-recursive makefiles for entire build system


  • filemanager popups no longer span multiple monitors
  • system operations no longer dim screen until action has begun
  • window stacking and focus restore is more accurate across restarts
  • gstreamer1 is now used for media previews
  • improved multiple monitor setup reliability
  • shaped windows now render more accurately

As always, stay tuned to the latest infrequent E updates on the release blog.


Enlightenment DR 0.19.0 GZIP30a5633be43a9bb33ce397afe0870511e7b148ea9c1f1a8536818354c20f2e31
Enlightenment DR 0.19.0 BZIP25fdd685ad2643a1e2fd8bc2b687923170c932e119b0f2d24cbb09b5867916d4b
Enlightenment DR 0.19.0 XZd7751ae73b6806c487da2438261546f28fbce25f6102002092500c55f9433a35

Disclaimer: Enlightenment developers cannot be responsible for any successes which occur during testing of E19.

Building and Dependencies

If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before compiling and installing to avoid possible conflicts during compilation. Please compile the dependencies in the following order (click for README):

  1. efl
  2. elementary
  3. emotion_generic_players
  4. evas_generic_loaders

Note: E19 depends on EFL v1.11 or newer.

Below are links to the project pages for each of the dependencies:

by zmike (Mike Blumenkrantz) at September 15, 2014 04:32 PM

Official Announcements

Python-EFL 1.11.0 release

Python-EFL 1.11.0 release

We are pleased to announce that Python-EFL 1.11.0 is now released and available for download.



For convenience the tarballs contain both the Cython sources and generated intermediary C sources, meaning you do not need Cython to compile the bindings. Full Cython sources are also publicly accessible from our git repository at:

More information about the python bindings can be found at:

What's New

In this series we are dropping the compatibility packages for pre-1.8 split bindings for efl and elementary. Many of the new features of efl and elementary 1.11 have been ported and the usual has been done in fixing bugs and optimizing. (see changes.html in the tarball for the full list of changes)


Kai Huuhko (17) (4 trivial commits removed):

  • Remove pre-1.8 Python bindings' compatibility packages
  • Elementary.multibuttonentry: Inject a Python object to created items
  • Evas: Add NULL safety to SmartObject callbacks, exposes a BUG
  • Examples: Elementary pep-8 (formatting) cleanup
  • Elementary.entry: Fix ref leak in filter callback handling.
  • Elementary: Fix object item tooltips
  • Fix build from tarball with Cython installed
  • add missing ecore-x include dir for elm
  • Add dummy commit count for dev build if git is not found
  • py3k compatibility fix
  • Fix check for Cython when building from git source
  • Examples: Add description to elm web exceptions, trivial updates to test
  • Release 1.11.0

davemds (25) (5 trivial commits removed):

  • Follow recent Eo api changes
  • Use a more eflish code style (still pep-8 compliant)
  • Follow recent Eo class names changes
  • New Map function: region_zoom_bring_in
  • Panes: new content_[left/right]_min_[relative]_size properties
  • Implemented missed ecore.x screensaver functions
  • Ctxpopup: new getters for items and the item_prepend method, with tests
  • Toolbar: new un/selected signals, with tests
  • Genlist: implemented search_by_text_item_get(), with a proper test
  • Gengrid: implemented search_by_text_item_get(), with a proper test
  • Gengrid: new property reorder_type, with test for reorder mode
  • Fix emotion.repr function
  • emotion: implemented missed smart signals
  • Expose object_from_instance and the inverse to other C code
  • Add version info in the efl package.
  • added extra debug info (to be manually enabled)
  • Simplify: no need to keep a local copy of the watch state
  • Cleanups: the filter are not used here
  • dbus_mainloop: reworked how we manage the dbus watch requests.
  • No need to call ecore init/shutodown here

godfath3r (1):

  • doc: add cleanup command in INSTALL file.

Building and Dependencies

If you have existing Python-EFL or the old split 1.7 release bindings installed, you may wish to uninstall them before compiling and installing to avoid possible conflicts during install and/or runtime.

To build the bindings you will need the following libraries:

  • python (Python 2.6+/3.2+)
  • efl (1.11)
  • elementary (1.11)
  • python-dbus (0.83+)

If you wish to compile using the Cython sources:

  • cython (0.19+)

To install the bindings run:

(sudo) python install

To generate the documentation locally you need:

  • sphinx (1.1+)
  • graphviz (optional)

To build the documentation:

python build_doc

For more information on available build options see:

python --help

Projects using Python-EFL

EpyMC - Media Center
Espionage - D-Bus inspector
Epour - BitTorrent Client
Econnman - Connman GUI
eInfo - System Information Tool
eAndora - GUI for Pandora Internet Radio
egitu - Git User Interface

... and many more that cannot fit in this short list.

by kuuko (Kai Huuhko) at September 14, 2014 05:24 PM

Official Announcements

Efl, Elementary and Evas Generic Loaders 1.11.2 release

We are happy to release another stable update for the 1.11.x series.

EFL fixes:

  • shutup ecore-x vsync stupid log domain failures
  • emotion - fix calling pos update cb for gst1 module in frame new
  • emotion - audio volume - leave as-is on file open/init
  • edje_cc now throws an error during link combination when the current part has no name
  • evas: fix build on armv7l. (T1620)
  • edje embryo stop_program() should stop pending actions
  • evas: let's freeze the canvas, shall we ?

Elementary fixes:

  • label: Fix size calculation for wrapped label
  • elm examples - missing -lm link - fix
  • elm_map: the widget use efreet cache home to save image files to, so efreet should be initialized.

Evas Generic Loaders fixes:

  • Improve LibreOffice binary detection



Building and Dependencies

If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before compiling and installing to avoid possible conflicts during compilation. If you are compiling the above, please compile them in the following order:


If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before building the above.

by stefan_schmidt (Stefan Schmidt) at September 12, 2014 07:41 PM

Go E19 ! Go !

Rumors And Heresay

Someone seems to have been starting up rumors about E19 release being this week. I don’t know who’s doing it, but they should knock it off this instant. If I find out who it was, they are going to be so grounded. No dessert for a month!

by e-releasemanager at September 09, 2014 01:28 PM

Go E19 ! Go !

The Septembering

It’s been a week, and things have been pretty busy. I’m bringing back an old segment that hasn’t been featured in a while.


E19 Changes From The Past Few Days Which You May Not Be Aware Of:

  • Coverity issues fixed
  • Wayland improvements
    • Pointer fixes
    • Resolution detection now more accurate
  • Systray improvements

Releases are pending.


And now, another new thing that will be appearing in the future:

by e-releasemanager at September 05, 2014 04:55 PM

Official Announcements

Efl and Elementary 1.11.1 release

We are happy to release a first stable update for the 1.11.x series.

EFL fixes:

  • evas: Evas_Wayland_Egl - change size of common gl context after egl make current according to current Outbuf's size
  • evas: Evas_wayland_Egl - fix black surface during resize
  • ecore_evas: Ecore_Evas_X - make sure that ecore evas post render is always called.
  • fix efl deadlock with thread queues
  • ecore_evas: Ecore_Evas_X - Fix broken rendering during rotation with resize (T1371)
  • eina_file: fixing wrong return value on access problems in file copy process



Building and Dependencies

If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before compiling and installing to avoid possible conflicts during compilation. If you are compiling the above, please compile them in the following order:


If you have an existing EFL or Elementary install, you may wish to delete its header files and libraries before building the above.

by stefan_schmidt (Stefan Schmidt) at August 29, 2014 01:04 PM

Go E19 ! Go !

Clean-Up Crew

Lots of things happening lately. Let’s recap:

* Epour 0.60 released

I’m sure none of us would use this for anything other than seeding torrents of our favorite Linux distributions.

* EFL 1.11 released

It’s a dependency of E19. Install it.

* Rage 0.10 released

It’s the next app written by raster after Terminology. Why are you not using it to read this blog?

* EFL Developer Day announced

Signups not yet available, admission will be extremely limited.

* E19 RC3 released

I took a selfie while writing up the release notes as part of a weekly segment that I’ll be doing leading up to EFLDD2014. I’ll be showing teasers of various new things that I’ll be unveiling at the conference. See if you can spot the newness in this week’s shot:

by e-releasemanager at August 29, 2014 05:15 AM

Interesting stuff on E

Rage media player 0.1.0 is out


So I have released the first version of Rage. Version 0.1.0


It is a simple video and audio player intended to be slick yet simplistic, much like Mplayer. You can provide 1 or more files to play on the command-line or just DND files onto the rage window to insert them into the playlist. You can get a visual representation of everything on the playlist by hitting the / key, or just hovering your mouse over the right side of the window. Mouse back over the left side of the window ti dismiss it or press the key again. It has a full complement of key controls if you see the README for the full list. It will automatically search for album art for music files, if not already cached, and display that. It even generates thumbnails for the timeline of a video and allows you to preview the position on mouseover of the position bar at the bottom of the window.

A feature list at this point:

  • Play video and audio files
  • Support a playlist via command-line
  • Insert to playlist via DND
  • Controls hide on mouse idle, and appear on mouse movement
  • Fullscreen mode support with automatic "no blank" support
  • Playlist visual previews and controls
  • Subtitle file support
  • Supports Gstreamer 0.10, Gstreamer 1.x, Xine and VLC as media engines via Emotion modules
  • Selection of media back-end via command-line
  • Album art fetch and caching
  • Video thumbnail timeline generation and caching
  • Works with any Evas engine (OpenGL acceleration, pure software etc.)
  • Works in X11, Wayland and Framebuffer direct support
  • Accelerated seek on keyboard fowrard/reverse
  • Drag gestures for seeking
  • Special different UI modes for pure audio and video

If you want to see more go to the about page at The Enlightenment Rage About Page.


Download Rage 0.1.0

Rage GIT repository

by raster (Carsten Haitzler (Rasterman)) at August 24, 2014 01:54 PM

~Brian Miculcy (last public version) is back online

From time to time developers in IRC channels talk about the good old times in Enlightenment development. Much has been already forgotten, for example the great ETK vs. EWL war. Awesome themes and animated backgrounds hadn't been updated to a newer API and got lost.
That's why i converted the last public version of to a usable format and moved it back online. Maybe developers and themers get nice inspirations from that old stuff - i miss these days... :)

by Brian 'morlenxus' Miculcy at August 20, 2014 03:18 PM

Interesting stuff on E

Yet another C object model - but better

It has been a while since I posted anything about E or EFL. I have been neglectful and it's time to change that. I want to do a quick intro on something really cool and new in EFL. It's part of a long-term move towards EFL 2.0. And that something is... Eo.

So the "G" world (GLib, GTK+, GNOME etc.) has GObject. We couldn't let them have all the fun, so We've made our own. We call it Eo (EFL Objects). It gives you objects in plain-old-C. Not just plain objects, but a host of related features. What do you get?

  • Inheritance
  • Interfaces
  • Mixins
  • Multiple inheritance
  • Method / property overriding
  • Properties
  • All object internals are opaque
  • Reference counting
  • Callbacks (all objects)
  • Cross references
  • Parent / child object hierarchy
  • Weak references
  • Key / value attachment on all objects
  • Code generation / maintenance to avoid boilerplate
    • Define your classes in Eo files cleanly
  • Multiple language support (beyond C) for bindings
    • Done by code generation and base type support
    • Currently C++ and Lua
      • C++ bindings use C ABI, not C++ ABI (fewer problems)
    • Plans to add Python and JS (v8)
  • Runtime type safety for objects
  • Runtime method / property call safety (if not supported becomes NOOP)
  • Object indirection to remove pointer bugs
  • Multi-call per object de-reference (lowers object access overhead)
  • Construction finalizers allowing calls during construction for lower setup overheads

And I'm sure I missed a few things. Why are we doing this? Why re-invent wheels? Why not just port to C++? Oh so many questions.

First - we like C. It just needs some extra filling out. Eo does just that. Changing our API to C++ would instantly shut out a lot of C developers and limit our audience, instead we are doing the inverse. We are adding a full and proper C++ API to EFL that is a direct 1:1 mapping to our Eo classes, properties and so on.

We can't feasibly use GObject without bringing in all of the GLib world with it, and GObject doesn't do many of the above things, so we're choosing a home-grown solution. In fact if you look at Eo a bit, you'll see it resembles JS, Python or Lua in terms of objects more than C++. In fact our object pointer indirection alone means we need to do it ourselves. But really - it's more fun to make your own object system in C.

But really it's a by-product of trying to clean up our libraries and their existing ad-hoc object model. This is basically what GObject did for GTK+ and we are now doing the same. We have a lot of interfaces that are duplicated in normal C functions because that becomes a necessity. Like:

evas_object_image_file_set(obj, "blah.png", "key");
edje_object_file_set(obj, "blah.edj", "group");



There are 100's of such examples across APIs in EFL. We are moving to clean this up and have "one class to rule them all ... and in the darkness bind them":

eo_do(obj, efl_file_set("blah.file", "key"));



Nice and simple now. So how do you make a new class? It's not hard. Make an Eo file like this:

class Tst (Eo.Base)
   data: Tst_Data;
   properties {
      name {
         set { /*@ This sets the name of the tst object */
         get { /*@ This gets the name of the tst object if set */
         values {
            const(char) *name; /*@ The name of the tst object as a C string */
      size {
         set { /*@ This sets the size of the object, and on success
                * returns EINA_TRUE, and on failure EINA_FALSE */
            return Eina_Bool;
         get { /*@ This gets the size set */
         values {
            int size; /*@ The size in pixels */
   methods {
      activate { /*@ This method will activate the tst object, and when
                  * called, any events listening to activated will be
                  * triggered */
         params {
            @in int number; /*@ The number of pixels to activate */
            @in const(char) *string; /*@ A label to display on activation */
         return Eina_Bool; /* If activation succeeds, return EINA_TRUE */
      disable { /*@ This disables the tst object to the level indicated */
         params {
            @in int level; /*@ This is the disabling level to use */
   implements {
   events {
      activated; /*@ When the tst object has been activated */
      disabled; /*@ When the tst object has been disabled */

Now to use the eolian code generators to fill in your class nuts and bolts. Let's assume you saved the above as tst.eo

eolian_gen -I /usr/local/share/eolian/include/eo-1 --gc --eo -o tst.eo.c tst.eo
eolian_gen -I /usr/local/share/eolian/include/eo-1 --gh --eo -o tst.eo.h tst.eo
eolian_gen -I /usr/local/share/eolian/include/eo-1 --gi --eo -o tst.c tst.eo

This generates your class eo header (tst.eo.h) and the body of the code (tst.eo.c) and the actual class implementation in tst.c. You never have to touch tst.eo.c and tst.eo.h as these are fully generated and have no need for human maintenance. So let's look at tst.c:

#include <Eo.h>
#include "tst.eo.h"

typedef struct

} Tst_Data;

EOLIAN static void
_tst_name_set(Eo *obj, Tst_Data *pd, const char *name)


EOLIAN static const char *
_tst_name_get(Eo *obj, Tst_Data *pd)


EOLIAN static Eina_Bool
_tst_size_set(Eo *obj, Tst_Data *pd, int size)


EOLIAN static int
_tst_size_get(Eo *obj, Tst_Data *pd)


EOLIAN static Eina_Bool
_tst_activate(Eo *obj, Tst_Data *pd, int number, const char *string)


EOLIAN static void
_tst_disable(Eo *obj, Tst_Data *pd, int level)


EOLIAN static void
_tst_eo_base_constructor(Eo *obj, Tst_Data *pd)
   eo_do_super(obj, TST_CLASS, eo_constructor());

EOLIAN static void
_tst_eo_base_destructor(Eo *obj, Tst_Data *pd)
   eo_do_super(obj, TST_CLASS, eo_destructor());

#include "tst.eo.c"

This is basically an empty useless class that does nothing, BUT almost all of the boring boilerplate code is done for you. We have no code to USE our test class, so let's make some in main.c:

#include <Eo.h>
#include "tst.eo.h"

static Eina_Bool
on_activated(void *data, Eo *obj, const Eo_Event_Description *desc, void *event_info)
   printf("activated callback for %p\n", obj);
   return EINA_TRUE; // pass event on to next cb

static Eina_Bool
on_disabled(void *data, Eo *obj, const Eo_Event_Description *desc, void *event_info)
   printf("disabled callback for %p\n", obj);
   return EINA_TRUE; // pass event on to next cb

int main(int argc, char **argv)
   eo_init(); // init eo
   Eo *obj = eo_add(TST_CLASS, NULL);
         eo_event_callback_add(TST_EVENT_ACTIVATED, on_activated, NULL),
         eo_event_callback_add(TST_EVENT_DISABLED, on_disabled, NULL));
   eo_do(obj, tst_activate(37, "Chickens"));
   eo_do(obj, tst_disable(99));
   return 0;

And we shall compile all of this into a small test binary with:

gcc tst.c main.c -o tst `pkg-config --cflags --libs eo eina`

And voila. A tst" binary. Let's now go and fill in our class implementation and update tst.c to be like:

#include <Eo.h>
#include "tst.eo.h"

typedef struct
   int size;
   char *name;
   Eina_Bool activated : 1;
   Eina_Bool disabled : 1;
} Tst_Data;

EOLIAN static void
_tst_name_set(Eo *obj, Tst_Data *pd, const char *name)
   printf("set %s\n", name);
   if (pd->name) free(pd->name);
   pd->name = strdup(name);

EOLIAN static const char *
_tst_name_get(Eo *obj, Tst_Data *pd)
   return pd->name;

EOLIAN static Eina_Bool
_tst_size_set(Eo *obj, Tst_Data *pd, int size)
   printf("size set %i -> %i\n", pd->size, size);
   pd->size = size;
   return EINA_TRUE;

EOLIAN static int
_tst_size_get(Eo *obj, Tst_Data *pd)
   return pd->size;

EOLIAN static Eina_Bool
_tst_activate(Eo *obj, Tst_Data *pd, int number, const char *string)
   printf("activate! %i '%s'\n", number, string);
   pd->activated = EINA_TRUE;
   // strictly correct...
   eo_do(obj, eo_event_callback_call(TST_EVENT_ACTIVATED, NULL));

EOLIAN static void
_tst_disable(Eo *obj, Tst_Data *pd, int level)
   pd->disabled = EINA_TRUE;
   //this is just fine. it's a local call within  an eo_do() already
   // due to eo_do handling its own stack. this works with any method
   // actually that this object inherits/supports
   eo_event_callback_call(TST_EVENT_DISABLED, NULL);

EOLIAN static void
_tst_eo_base_constructor(Eo *obj, Tst_Data *pd)
   eo_do_super(obj, TST_CLASS, eo_constructor());
   pd->size = 77;

EOLIAN static void
_tst_eo_base_destructor(Eo *obj, Tst_Data *pd)
   eo_do_super(obj, TST_CLASS, eo_destructor());

#include "tst.eo.c"

And now things run and do something when we run ./tst:

set Smelly
size set 77 -> 100
activate! 37 'Chickens'
activated callback for 0x8000000000000001
disabled callback for 0x8000000000000001

Of course the above eolian_gen commands would become part of your Makefiles or build setup. it will even "maintain" the implementation file for you (tst.c in the case above) and add methods as you add methods and properties in your class. It won't remove old ones - you'll have to do that, and if parameters change, you'll need to do that yourself, but a lot of the manual footwork has been removed by automated code generation.

Now what if i want a C++ binding to my new class? Well that's easy:

eolian_cxx -I /usr/local/share/eolian/include/eo-1 tst.eo

This will add the base Eo include dir to scan for Eo files and generate bindings for the class in tst.eo and out will pop tst.eo.hh. I won't paste the .hh file here as it is large and complex template-based C++, but you now could write some C++ code to use the same C class such as:

#include <Eo.hh>
#include "tst.eo.hh"

int main()
   efl::eo::eo_init eo_;

   ::tst obj;
       std::cout << "activated callback for " << obj._eo_ptr() << std::endl;
       return true; // pass event on to next cb
       std::cout << "disabled callback for " << obj._eo_ptr() << std::endl;
       return true; // pass event on to next cb
   obj.activate(37, "Chickens");
   return 0;

Just compile it like so:

gcc -c tst.c -o tst.o `pkg-config --cflags eo eina`
g++ tst.o -o tstcc -std=c++11 `pkg-config --cflags --libs eo-cxx eina-cxx`

This ensures you build the pure C object file to tst.o then link it in as part of compiling

So Eo now makes doing objects in C a breeze. It removes a lot of the footwork in C that would make doing objects painful (and which often drives developers to C++ or some other language). It allows you to build simple C APIs that are usable not just from C in an OO way, but in C++ as if they are native C++ APIs, and in other languages too. We're fleshing out the Lua support at the moment, and other languages will appear as time goes on. This isn't just useful in EFL, but for anyone wanting to make simple OO code in C, be it in embedded devices, phones, desktops, laptops or servers. We happen to be doing it so we can offer far nicer APIs for EFL in future as well as clean up lots of internals, provide far more call safety at runtime, but I am sure this may sole some other problems people have out there.

We invite people to test this out and if you're interested, provide a bindings generator for your favorite language or runtime. This then allows such a language to be a "first class citizen" when using EFL, and any other APIs written using Eo. Such binding generation is then automatic with no human intervention. That is the only sane way to support bindings for languages as manual binding eventually fails.

Now what is object indirection? Well like GObject and older GTK+ before it, Qt and others, our objects before Eo were pointers to memory where the object data is stored. This allows programmers to "do bad things" (by accident) and pass in invalid pointers. We used to solve this by checking the pointer is NULL or not, and if not NULL, de-referencing it and checking for some magic numbers in the memory it points to to ensure the object is there and the right type. No more. Now what look like pointers are actually object IDs. They are not able to be de-referenced. They are broken up into separate fields (different bits in the pointer now have different meanings), and looked up in a table. The table is managed in memory away from normal heap allocations and managed by Eo core. This table in turn holds locations in memory of the objects. This means that an invalid pointer is always caught as it fails table range checks or the table entry is NULL. It even tries to detect false positives with generation count checks. This makes object addressing far more robust and basically almost impossible to get to crash. Eo brings this along with it to EFL, improving stability and correctness even when we don't find the bug and a user unfortunately has to encounter it.

This extra object reference checking leads us to the multi-call capability in Eo. This is where you do something like this:

      eo_event_callback_add(TST_EVENT_ACTIVATED, on_activated, NULL),
      eo_event_callback_add(TST_EVENT_DISABLED, on_disabled, NULL));

You can call multiple methods on an object with a single object de-reference/check. This amortizes the cost of such checks over more calls, thus eventually negating them as we now do less checking that we did before on average per call.

Eo also does a check on every method call. If the object does not support that interface/class the call is turned into a no-op and safely returns. This is now guaranteed for every single method call at the C level, so making mistakes and calling the wrong method on the wrong object simply results in some complaints to stderr, and safely marching on.

So much is added and improved with the addition of Eo. Even the existing "legacy" C calls are auto-generated and wrapped on top of Eo calls, so in using EFL today, you are already using Eo, just with a very simple wrapper function on top for compatibility. Every object in EFL is now an Eo object, so you can even mix-and-match old style C calls and newer Eo ones. Eo is a huge step forward for EFL and hopefully is useful to others as well.

by raster (Carsten Haitzler (Rasterman)) at August 18, 2014 03:41 AM


Elive 2.3.5 beta released

The Elive Team is proud to announce the release of the beta version 2.3.5

This new version includes:

  • EFL (enlightenment libraries) are updated to the beta version 1.11
  • Darktable and librecad applications included by default
  • Nightingale is now available from the repositories
  • Right-clicking on a PDF in the File Manager will now give you the option to shrink it
  • Interactive git shortcuts for the Shell
  • Users Home directory is now in their default language
  • Improvements were made to Tmux when

Check more in the Elive website.

by Thanatermesis at August 15, 2014 09:08 PM


Elive 2.3.4 beta released

The Elive Team is proud to announce the release of the beta version 2.3.4

This new version includes:

  • A “Send-to Dropbox” option has been added to the File Manager
  • Right-clicking on a Movie in the File Manager will now give you the option to get the subtitle
  • Applications menu has been redesigned to be more intuitive
  • Laptop wifi switch now works properly on re-activation
  • Keyboard hotkeys for volume and mute control is now configured automatically.

We appreciate your feedbacks and …

Check more in the Elive website.

by Thanatermesis at July 24, 2014 07:39 PM


Elive 2.3.0 beta released

The Elive Team is proud to announce the release of the beta version 2.3.0

This new version includes:

  • Updated Linux kernel to 3.14 with Reiser4 patch, including a much wider range of wifi and audio card drivers for newer computers.
  • Backports for Virtualbox, nvidia and fglrx drivers
  • Enlightenment has a much more friendly menu of applications now
  • Debian security repository is included by default
  • New games included: “Super Mario War” and some “game and watch” simulators
  • Elive Installer includes fixes

Check more in the Elive website.

by Thanatermesis at June 26, 2014 03:10 PM

~Andy Williams

Accelerating the return to enlightenment (With linux on a Yoga 2 Pro)

“If you want to succeed then you need to immerse yourself in the problem” – wise advice from a business mentor of mine… My long serving Apple Macs run everything – work, media, side project coding and now VMs filled with Linux and Enlightenment. They are shiny and solid but have strange keyboard layouts, nonstandard hardware and a bad implementation of virtual desktops that get in the way of desktop virtualisation. So for the first time in nearly 10 years I bought not-a-mac.

This new PC laptop (note not a “windows PC”, I hate that term – it came with windows but that’s not a defining feature…) should be a great device for pushing the limits of modern display and input software. I wanted something light, thin and powerful with at least a 13″ screen. Essentially a competitor to the MacBook Air, but more modern and without the Mac downsides – also avoiding a lookalike, something that’s cool in its own right.

Let’s face it there aren’t a lot of devices in this class but I settled (after some time) on the Lenovo Yoga 2 Pro. This is a solid core i7 device with a decent amount of RAM and SSD storage. The screen is an impressive 13.3″ that has more pixels than my retina 15″ MacBook Pro – as well as being a touch screen too! Couple that with the fact that it inverts to become a tablet. All of those features are packed into a bright orange shell that is no heavier or larger (at the thickest point) than a MacBook Air. Impressive!

So after a short trial of windows 8.1 (yuck! What a confused system) I installed arch Linux (details in a different post – to follow) and it went very smoothly. Out of the box it was up and running with full res video and complete audio in & out. The keyboard (including all the special function keys), trackpad and touchscreen also worked perfectly. After installing the wpa_gui wi-fi was complete too (a little config juggling was required to connect to my secured wifi and download the packages but nothing too taxing). And most surprising when the keyboard is folded back on the screen it is disabled as you expect – though I think this may be a hardware feature. As of now all that is not working is automatic screen rotation (the gyroscope seems non-standard) and the windows icon/button on the screen which I had not realised was a button.

The only issue with the machine so far has been the insanely high pixel density. You can work around it by telling Xorg to scale 2x but you lose the quality so I didn’t want to do that. Thankfully Enlightenment has built-in support for output scaling so I went right ahead and installed the latest version from their source. As with any large compiling from source task it took a while to get all the dependencies but I put that in a script for future use. The compile and install went well – grab EFL, Elementary, Enlightenment and Entrance for a good base experience. Git master is really stable and I really enjoy being on the cutting edge but if you don’t have that thirst then you should probably grab release tarballs instead.

This new machine has given me a great platform to immerse myself in Linux and Enlightenment. Scaling and touch interfaces are things that need a little work still but I’m helping out with that. Next I’m going to be further developing the Enlightenment IDE (EDI) which is already a good place to be working on EFL based code. It’s a work heavily in progress but I’m hoping to get some more contributors soon and start pulling in cool new features to get more Software Engineers into creating apps for Enlightenment.

Want to know more about my E install or Linux on the Yoga 2 Pro? Drop a comment below or hit the contact page.

Filed under: Coding, Enlightenment, Hardware, Operating Systems

by Andrew Williams at June 24, 2014 12:25 PM

~Andy Williams

Building an Enlightened IDE

So I mentioned before a project called EDI and I’ve been posting some info online but I never really described it here. So – for my faithful followers – what am I up to?

In absence of other active projects (such as growing a company, establishing a software platform or maintaining apps) I decided to get back to some Enlightenment development. After around 8 years off the project a lot had changed – I was struck by how complete the EFL APIs had become but was also surprised that Linux still suffered from a lack of polished development environments.

And so I figured 3 birds with 1 stone -

  1. Learn the new EFL APIs and help with some bug fixing
  2. Create a slick new IDE for Linux
  3. Reduce the barriers for new developers looking to create apps for Enlightenment.

By creating a native IDE application using the Enlightenment libraries we can harness their APIs and render scripts to provide a powerful integrated environment. With any luck we’ll be able to bring in various other E projects to provide graphical editing or version control etc.

I also just completed the icon for the app – see above. I think it works quite well, I hope you guys like it too…

Please stop by the planning page which is kept up to date with progress. I’ll also be posting more updates here as and when there are things to report. Hopefully there will be a great app here for everyone to enjoy soon.

Filed under: Coding, Enlightenment

by Andrew Williams at June 15, 2014 10:07 PM


Installer Module Demo


Installer Code:

Invitation Code:

Receive notifications for Elive Stable releases

Check more in the Elive website.

by Deon Thomas at June 09, 2014 02:31 PM

~Boris Faure

Miniview of the history in Terminology

Lately I have been working on a new feature for terminology: render the history in a small widget that I call the miniview. This feature can be found in trendy code editors.

It started as an old patch from Galatsanos Panagiotis back in June 2013! I made it work with the current code base and iterated over it.

A picture is worth a thousand words: terminology showing the miniview

The miniview is shown on the right. It can be shown with hitting Ctrl-Shift-h. (I plan to make keyboard shortcuts configurable soon, but it will probably not hit terminology 0.6)

Each character is converted to a single pixel. It is possible to click on it to scroll the terminal to that position in the history.

The widget can be scrolled up or down with the mouse wheel cause it may not show the whole history on one screen. PgUp/PgDown scrolls by steps of 25 lines while Shift-PgUp/PgDown scrolls by a whole screen. Alt-PgUp/PgDown, Ctrl-PgUp/PgDown do the same.

Hitting Ctrl-Shift-h or the blue cross on the top left corner will close the miniview.

Now it's time to fix some bugs to be able to release terminology 0.6 next month!

by billiob at May 15, 2014 12:00 AM

~Andy Williams

Linux, is it ready?

So I’m trying out Linux for the first time in over 5 years. Mainly to get back on board with Enlightenment development, partly due to frustrations with Mac OSX and also because every software engineer should be up to speed with how it’s progressing. This leads me to the question if is it ready…

Ready for what? Wide stream adoption? Frustration free desktop? A better alternative to what’s out there? “Yes” and “It depends” get thrown in there as answers – it depends on your requirements and the ability to pick the right distro. Ubuntu offers a seamless install and gets you booted to a complete system with all the typical user software pre-installed, their software manager akin to Apple’s Mac App Store is essentially a recommendations engine on top of the apt-get package manager and works well. Of course as a geek it’s cheerful light grey rounded-ness and hiding of details quickly missed the point – Mac does that well and I don’t see Canonical beating Apple at the user experience game. Arch Linux is a widely used engineers choice – it offers close to the wire control without the pain and ricer obsessiveness over customised packages of Gentoo. There is no installation UI or default desktop but it does offer great control, a solid base for development (1 package sets up a full C/C++/autofoo environment) and it has a command line package manager called “pacman;).

So should I switch? Well as you’re already reading this then you should probably give it a shot, yes. Don’t ditch your current system and move completely – compatibility is still an issue and multimedia has a couple of issues (mostly due to closed source licenses, patents and no silverlight plugins) but it really does seem ready. Don’t recommend it to your Gran though – as much as I hate software monopolies they do enable people to easily discuss simple tasks or basic problem fixes with their non-techie friends. You do not want even more “help fix my computer” calls right?

So, given that it’s ready for use, will you like it? Is it really something that Microsoft and Apple should be worried about? I’ll cover that in a future post in my return to enlightenment series.

Filed under: Coding, Enlightenment, Operating Systems

by Andrew Williams at May 14, 2014 11:31 PM

Interesting stuff on E

E19 Theme Migration

The last migration guide (E17 -> E18) was posted too close to the E18 release, so this time I'm getting it out a few years in advance.

Behold, the updated theme migration guide!

by zmike (Mike Blumenkrantz) at May 11, 2014 06:11 PM