Official Announcements

Efl and Elementary 1.9.3 and Enlightenment 0.18.7 release

We are happy to release another stable update for the 1.9.x series and Enlightenement 0.18.7.

EFL fixes:

  • build: Disallow non-working sdl + opengl ES combination (T856)
  • evas/proxy - redraw proxy source properly.
  • edje_cc: Fix the crash when compiled wrong edc file containing empty part
  • evas - fix incorrect object reset.
  • ecore-evas - fix object cursor to not delete the same cursor when set
  • Evas cserve2: Fix crash in elm_test GLView
  • ecore-con - deal with internal buffer growing over 2g in size
  • fix swap buffers with damage to not detect if ext str is not there

Elementary fixes:

  • elm win - fix tracking of current position to properly store it in win obj
  • spinner: crash issue on deletion fix
  • fix left over soft cursors in elm (T893)

Enlightenment fixes:

  • unify temp module temperature_get_bus_files() functions
  • check notification icon size correctly
  • correctly check evry trigger matches
  • comp config dialog correctly detects effects disabled/fast states
  • efm current .desktop fetching now returns the right .desktop
  • swallow efm background objects after applying theme
  • ibar now scrolls correctly during drags
  • no longer place windows at 0,0 during restart
  • music_control: Use correct markup for metadata text.



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 April 15, 2014 12:56 PM

~Boris Faure

Terminology supports the Fraktur escape sequence!

Thanks to a tweet from @resiak, I've learnt that ECMA-48 - Control Functions for Coded Character Sets provides some escape codes to diplay Fraktur!

According to wikipedia,

Fraktur [fʁakˈtuːɐ] is a calligraphic hand of the Latin alphabet and any of several blackletter typefaces derived from this hand. The blackletter lines are broken up – that is, their forms contain many angles when compared to the smooth curves of the Antiqua (common) typefaces modeled after antique Roman square capitals and Carolingian minuscule.

Not long ago, PragmataPro, the great monospace typeface I use every day got support for such characters.

I've spent few minutes to let terminology handle those escape codes.

If you follow the git version, you can try it like that:

echo "\033[20mabcdefghijklmnopqrstuvwxyz\n\033[0m"

Mandatory screenshot of the feature: terminology rendering some Fraktur characters

by billiob at April 06, 2014 12:00 AM

~Jorge Luis Zapata Muga

Egüeb's EFL Integration

On you'll find the Egüeb's EFL integration project.
Basically this projects does all the links between the different EFL technologies: Ecore, Evas, Edje and Egüeb.

Given that Egüeb is based on the "features" concept to support different features on the documents (drawing, animations, input events, etc) all of theme can be easily matched against EFL's abstraction. For example all the input events are handled automatically using the Ecore Event abstraction. For animated documents (documents that use the SMIL elements) an Ecore Timer is used. For drawing an Ecore Idler is used, etc.

Window abstraction:

You can use any Egüeb document implementation along with the new Efl Egüeb Window type. With that you can easily create a window for drawing any Egüeb document. For example:

Efl_Egueb_Window *w;
Egueb_Dom_Node *doc = NULL;
Enesim_Stream *s;

/* Load the file */

s = enesim_stream_file_new("some.svg" "rb");
/* Parse it */
egueb_dom_parser_parse(s, &doc);

/* Create the new window */
w = efl_egueb_window_auto_new(doc, 0, 0, width, height);

Will show a window with the contents of the SVG file drawn and you can interact with it in a similar way to what Ecore Evas abstraction does.

Smart Object:

Along with the window abstraction, there is also an Evas Smart object. With it you can embed a any Egüeb Document into an Evas scene. For example:

Evas_Object *o;
Evas *evas;

o = efl_egueb_smart_new(evas);
efl_egueb_smart_file_set(o, "some.svg");
evas_object_move(o, 0, 0);
evas_object_resize(o, 320, 320);

Edje external object:

The last abstraction provided on Efl Egüeb is an Edje external object to easily include an Egüeb Document into an edje scene.
For example:

collections {
group { name: "main";
externals {
external: "egueb";

parts {
part { name: "anim_svg_example";
source: "egueb";
description { state: "default" 0.0;
params {
string: "file" "some.svg";

by turran ( at April 02, 2014 07:23 PM

Official Announcements

EFL and Elementary technology preview for 1.10

We have finished our first round of merge and stabilization phase and are now in the second and last cycle for 1.10. This could be a good time to put together what we have so far for packagers to test. Please provide feedback of this is useful for you or if you are fine with waiting for the first alpha release which would happen right after the second merge window closes.

This should not be considered a full release but more a current snapshot of what will await you for 1.10

New features for EFL would include:

  • eina: add eina_inarray_resize @feature.
  • eina: add eina_accessor_clone and update all Eina_Accessor to take advantage of it.
  • eina: add a C++ bindings to Eina @feature.
  • @feature - Apply NEON intrisics improvement to rotation
  • Evas textblock: Implemented mid-contextualization formatting.
  • evas-drm: Add evas_drm to build order for Evas drm engine
  • evas-drm: Add Evas Drm Engine (software only currently)
  • evas-drm: Add option to enable drm hardware acceleration
  • evas-drm: Start on hardware-accel support for drm
  • evas-drm: Triple buffer by default.
  • evas-drm: Fix opening of drm card
  • evas-drm: Start on hardware Plane support * evas-drm: Add vsync/non-vsync support to evas_drm code
  • evas-drm: Ddd support for setting vsync with env variable.
  • edje: @feature to include license in edje file. (T1027)
  • edje: add support of last input entered in password mode to be always visible in entry.
  • eio: make it possible to limit the amount of memory used by threads.
  • eina: make Eina_Error thread safe.
  • edje: add AUTHORS and more than one license file to Edje.
  • ecore-drm: Add Ecore_Drm code
  • ecore-drm: Add autofoo for ecore-drm
  • Eet: Added vieet a tool to edit eet files.
  • eina-cxx: Added eina_log support for C++, using IOStreams syntax
  • ecore-drm: Add API function to return the vt fd
  • ecore-drm: Add dependency on xkbcommon
  • ecore-drm: Add code pass along key events to ecore_event
  • ecore-drm: Set the window of the Ecore_Event_Key structure
  • ecore-drm: Add code to handle modifiers in a key event
  • ecore-drm: Add code to handle mouse input
  • ecore-drm: Add code to handle modifiers in a key event
  • ecore-drm: Add code to handle mouse input
  • evas/font: Added evas_font_path_global_* APIs.
  • Eo: Made eo id for classes a bit more secure.
  • ecore-drm: Add API function to return the drm device name
  • ecore-evas-drm: Add support for resize and move callbacks
  • ecore-evas-drm: Add support for setting focus_in & focus_out callbacks
  • ecore-evas-drm: Add support for setting the mouse in & mouse out callbacks of the ecore_evas
  • ecore-evas-drm: Add support for ecore_evas_move function
  • ecore-evas-drm: Add support for ecore_evas_move_resize
  • ecore-evas-drm: Add support for rotation set
  • ecore-evas-drm: Add support for setting the title of the ecore_evas
  • ecore-evas-drm: Add support for ecore_evas_name_class_set
  • ecore-evas-drm: Add support for setting size hints
  • ecore-evas-drm: Add support for ecore_evas_object_cursor_set
  • ecore-evas-drm: Add support for ecore_evas_layer_set
  • ecore-evas-drm: Add support for ecore_evas_iconified_set
  • ecore-evas-drm: Add support for ecore_evas_borderless_set
  • ecore-evas-drm: Add support for maximized, fullscreen, withdrawn, and ignore_events settings
  • ecore-evas-drm: Add support for alpha & transparent setting
  • ecore-evas-drm: Add support for setting aspect of ecore_evas
  • edje_cc now supports program.targets keyword for adding N targets in one line
  • edje_cc now supports group.remove for removing parts from inherited groups
  • edje_cc now supports part.inherit for copying attributes of parts within a group more easily
  • eeze_udev gets more helper functions
  • edje_cc now supports program.sequence for more easily chaining programs together
  • edje_cc can now use group.program_remove to remove inherited programs
  • edje_edit: function that will return the source code of the loaded edje edit object.
  • Eolian integration

New features for Elementary so far:

  • popup: implemented widget item focus feauture.
  • list: implemented widget item focus feature.
  • list: Added descriptions for the newly introduced item,focused/item,unfocused smart callbacks.
  • popup: Added descriptions for the newly introduced item,focused/item,unfocused smart callbacks.
  • hoversel: Added "item,focused" and "item,unfocused" smart events for widget items.
  • win - add accel preference option to elm windows
  • focus: Added focus highlight clip disable feature. (T1056)
  • focus: Added optional focus feature - focus movement by mouse_in.
  • toolbar: implemented widget item focus feature.
  • Eolian integration



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 April 01, 2014 01:48 PM

~Andy Williams

Update on progress with EDI

Here’s the latest screenshot of an IDE i’m putting together using the EFL (Enlightenment Foundation Libraries). You can check it out from – let me know what you think…

Filed under: Coding, Enlightenment

by Andrew Williams at March 31, 2014 09:59 PM

Official Announcements

Efl and Elementary 1.9.2 and Enlightenment 0.18.6 release

We are happy to release another stable update for the 1.9.x series. Within the several fixes we also fixed another ABI break in EFL that got introduced in 1.9. (We are improving our tooling and process to avoid these in the future).

Mike also asked me to include his announcement for Enlightenement 0.18.6 here. See below.

EFL fixes:

  • Evas filters: Fix 1-D blurs on a single buffer
  • Evas filters: Fix memory leak when destroying the object
  • Ecore x: Add back the two symbols removed in 1.9.
  • eet: fix tokenizer's escape logic.
  • edje: check font change in edje text part cache infra.
  • Evas cserve2: Fix client crashes when a file changed
  • Evas gl: Fix clip in image_draw if it's not set
  • edje_cc no longer fails on{}
  • edje_cc now correctly handles lack of state int in STATE_SET action
  • edje_cc also checks min args correctly for STATE_SET actions
  • Evas filters: fix potential memory leak
  • edje_cc uses macros for some of its handler setup
  • evas/gl - fill up missed blend mode.

Elementary fixes:

  • theme overlays - fix to prepend on overlay to be semantically consistent
  • entry - fixed calc issue of the wrap none mode.
  • segment_control, toolbar: Fixed broken scale of widget item.
  • entry - entry did word wrapping even the mode was ELM_WRAP_NONE.
  • list/genlist: Fixed Home and End key event handling routine.
  • diskselector: Compare correct variables. (CID1193236)
  • atspi_object: Added missing comma. (CID1193238)
  • index: Set variable to NULL after free. (CID1193250)
  • access: Fixed memory leak. (CID1193244)
  • fix scrollbar to be clickable even if vieport is tiny compared to content
  • naviframe : Fixed the overlap issue during multiple push.
  • genlist needs to iterate exactly once over a fixed list when deselcting all items
  • list: Fixed item multi/single selection routine to skip disabled item correctly.
  • genlist: Fixed item multi/single selection routine to skip disabled item correctly.
  • prefs: Add EVIL_LIBS to build to avoid problems with missing regex.h under mingw

Enlightenment fixes:
This bugfix release primarily focuses on fixing issues reported by the
Coverity static analyzer.

  • wl_desktop_shell builds out of source tree
  • get entry width based on viewport size, not entry size
  • fix hiding of windows when delete is requested
  • don't deref teamwork pointer after null check
  • don't deref possibly-null value in mouse bindings
  • correctly calculate minimum flowlayout rows
  • efm_op no longer tries to close invalid fds during delete ops
  • don't use external log domain in systray
  • don't use external log domain in music player
  • don't crash when saving screenshots with no file extension
  • don't crash on possibly-null gadman bg string extensions
  • check for unicode string end in client menu
  • don't crash when passing NULL desk to e_border_under_pointer_get
  • set connman pending.disconnect when disconnecting a service
  • don't iterate with or access freed pointer in comp match dialog
  • ensure use of non-garbage values for menu item icon placeholders
  • use more descriptive + accurate buffer size in batget iterator
  • prevent out of bounds access in systray theme setup
  • prevent out of bounds write in e_intl_locale_parts_get()
  • ensure null termination of string in xsettings config
  • dim/undim actions don't require acpi triggers



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 March 25, 2014 01:00 PM

Official Announcements

Enventor 0.2.0

After three months of development, we are pleased to announce the release of Enventor 0.2.0

by Hermet (ChunEon Park) at March 19, 2014 07:04 AM

Go E19 ! Go !


Full Wayland support, based on DRM, has landed from Chris “devilhorns” Michael’s private store of E features. He has helpfully added a README.wayland file which provides suitable amounts of warnings and documentation to prepare the average user for a brand new type of crashing. I’ve helpfully inlined the README here:


Wayland support in Enlightenment 0.19.0

Caution: Support for running Enlightenment in a Wayland-Only
configuration is considered Highly Experimental !! Use at your own
risk !! We are not responsible if it nukes your files, burns up your cpu,
kills your cat, sells your house, divorces you, or otherwise messes
Anything up !

Use at your own risk !! You have been warned !!


Aside from the normal requirements that Enlightenment needs, there are
a few things to note in order to get Enlightenment to build without
X11 support.

Firstly, you MUST have EFL built with the following options:


This Readme does not address the dependencies needed to enable Wayland
in EFL. If you require any information for that, please see:

If you would like support for EGL in Wayland, then also build EFL with:


The above options can be enabled for EFL without any adverse effects to
existing applications.

Next, you will need to adjust the options that you pass to
Enlightenment during the compile phase.

Please note, we recommend installing This version of Enlightenment into it’s
own separate prefix so that you can still safely fallback to the X11 version.

This can be done by passing:


Now, on to the magic bits ;)

In order for Enlightenment to be compiled without X11, using Wayland
only, you will need to pass a few more options to the configure stage
of Enlightenment:


Since this is all still a work-in-progress, there are a few
Enlightenment modules that have not been “fixed” to work without X11
yet. Those will need to be disabled:

–disable-everything (don’t worry, this is just the everything module)

At this stage, you should have EFL properly built, and Enlightenment
properly built. Let’s move on to running it…


Hopefully at this stage you have successfully built EFL and
Enlightenment in preparation for a Wayland-only setup. Congratulations
!! Now, let’s get it running…

The following steps assume you are currently at a Virtual Terminal
without anything else running (ie: no other window managers, X11, etc).

In order for Enlightenment to function without X11, we need to setup
the environment. In your current tty, do:

export E_WL_FORCE=drm
export ELM_ENGINE=wayland_shm (or wayland_egl)

This will make sure that Enlightenment renders using DRM, and any
Elementary applications use a Wayland engine.

At this point, you should just be able ‘cd’ to the Enlightenment
prefix where you installed, and issue:


Please Note: It is suggested that you create a separate configuration
profile with only a Minimum of modules loaded. Due to the experimental
(and ongoing) status of Wayland-Only support in Enlightenment, Many
modules May Not Work. Very few have actually been tested yet !!

If you have a separate configuration profile (as suggested) that you
would like to use, you can tell Enlightenment to use that when you
start it:

./enlightenment_start -profile <my_profile>


Please Note: There is currently NO support for running X11
applications with this !! So basically, your web browsers won’t work,
don’t expect to be able to run Firefox, Thunderbird, or practically
Any Other X11 application yet. About the only things “known” to work
so far are EFL/Elementary applications.


Yes, there are Lots of them !!
Yes, I am already aware of 99.9% of them.
No, you do not need to start reporting them yet !!

When we feel that the work is reaching a “finalizing” stage, we will
put out a request for actual testers and bug reports !

You are here because you want to play…because you want to
experiment…because you want to be “cool” ;) You are not hear to nag
me with complaints & reports about things I am already well aware of
;) Save yourself some time, and me some stress !! ;)

by e-releasemanager at March 18, 2014 02:03 PM

~Jorge Luis Zapata Muga

Eon again

So after a hard time developing Egueb and mainly the SVG library. I wanted to try again Eon for changing some perspective and see if Enesim's API was still enough for such library.

After taking a look on the old code and see how hard it depended on Ender (the old object description library) I decided to make it use Egueb itself as it's core object system. It was natural given that Egueb's Dom implementation has improved so much that at the end it fits perfect on what Ender was trying to do.

So first I took Ender's dependency, coded some initial widgets using DOM's way of doing it, ported Escen to use SMIL elements (The 'set' and 'animate' elements) and put all the pieces  together to be as close as what it was before but using another libraries behind.

The result is that I can declare the application's widget using XML (that means that I can also do CSS on the widgets for fine tuning some specific attributes) load it and interact with it.

This is the file contents I used for the following video

<stack orientation="vertical">
<button id="button01">
<label>My very own label</label>
<button id="button02">
<label>My second button</label>
<button id="button03">
<label>My third button</label>
<button id="button04">
<label>Button 4th</label>

And this the theme used for drawing the whole application:
<object ns="eon_drawer_basic" name="button" id="button">
<state name="default">
<set attributeName="border-color" to="#555555"/>
<animate attributeName="fill-color" from="#555555" to="#cccccc" dur="0.8s" repeatCount="indefinite" />
<state name="mouseover">
<animate attributeName="fill-color" from="#555555" to="red" dur="0.8s" repeatCount="indefinite" />
<state name="mouseout">
<animate attributeName="fill-color" from="#555555" to="#cccccc" dur="0.8s" repeatCount="indefinite" />
<object ns="eon_drawer_basic" name="label" id="label">
<state name="default">
<set attributeName="color" to="gray"/>
<set attributeName="font" to="Verdana"/>
<object ns="eon_drawer_basic" name="eon" id="eon">
<state name="default">
<animate attributeName="color" from="#ffffff" to="#cccccc" dur="0.8s" repeatCount="1" />

And this is the result:

The window has been created using the new efl-egueb bridge I've created. Basically the above is an Ecore_Egueb_Window in a way is similar to an Ecore_Evas, but instead of using an Evas for drawing it is using the renderer interface of Egueb's Dom, which basically has an Enesim renderer. I'll explain later how Egueb's approach can be used with EFL's core libraries.

by turran ( at March 07, 2014 07:58 PM

Enesim status

It has been a year and a half from the last post, but none of the developments have stopped during this time. I'll try to do several posts in the following days explaining the different improvements on the whole stack of libraries.

In Enesim, I've been porting all the renderer algorithms to the OpenGL backend and thus, all the libraries that depend on Enesim for drawing can use OpenGL out of the box without any specific modification but passing an Enesim_Surface created by the OpenGL's Enesim_Pool.

Another improvement is that finally the NVIDIA's path extension can be used (when available) for the path renderer, besides Enesim own software and OpenGL implementations.

On the current stack of libraries that I'm developing, having OpenGL support means that having SVG graphics/scenes using OpenGL for drawing is possible. In the same way, drawing Eon's widgets can be done using OpenGL without any special effort.

by turran ( at March 07, 2014 07:22 PM

Go E19 ! Go !

The Return Of The Releasinator

In what has become a frustratingly long process compared to previous releases, 1.9 alpha (MYSTERY RELEASE 2K14!!!) is now out. I included a special Billy Mays for all my loyal readers here as well.


by e-releasemanager at February 11, 2014 09:58 PM

Go E19 ! Go !

The Iceman Cometh

Just a quick update today, the EFL 1.9 release freeze has begun. The release is scheduled to happen in 2 weeks, so hopefully Stefan Schmidt returns from his glacier tours before then.


Our wiki received some hacks last night which should allow reading without being logged in. A big thanks to Carsten “Widget Wrangler” Haitzler for that.


Most E19 commits recently have been related to fixing shadow display. Not very exciting. Stay tuned, however: there’s more announcements in the works!

by e-releasemanager at February 10, 2014 05:06 PM

~Jerome Pinot

SlackE18 is out!

After several months maturing, I’m finally publishing my E18 packages for Linux Slackware. You will find the EFL 1.8.5, elementary 1.8.4 and Enlightenment 0.18.3. Most of the modules are broken and have been removed but I added a few EFL related applications.

E18 is not much than an upgrade to E17. But on the packaging side, many things changed. The biggest part is the merge of all the EFL in one build system, the change in theme and configuration files and a lot of break in modules. I actually started SlackE18 as a branch in SlackE17 repo but so many things were different that it just didn’t worth keeping all the SlackE17 history. SlackE17 is actually quite old as I started the project in 2005 and the repository as grown to a big size (2.4GB for now). It was a good time to rework the build system a little too. SlackE18 is then a separate project.

From the user point of view, there is no easy way to upgrade from SlackE17 to SlackE18 : change in the configuration files (config will start from scratch), most of the old modules not available, maybe graphic problem due to the fact that E18 use only compositing, etc. I’d rather keep SlackE17 around for some time.

The EFL >= 1.8 have sound support but it requires PulseAudio which is not available in Slackware. If you have installed PulseAudio, you could rebuild the efl package by passing PA=yes to the SlackBuild.

I added back ConnMan to SlackE18 as econnman seems stable enough.

As for SlackE17, you can install SlackE18 using the SourceForge tarball or by using Slackpkg+. You’ll need Slackware 14.1 (i486, x86_64 or ARM).

SlackE18 website:
Tarball download:
Slackpkg+ information:
Packages list:

by ngc891 at February 09, 2014 08:16 AM

Go E19 ! Go !

Tiling In The Name Of

I don’t have anything worthwhile of my own to blog about, so I’ll keep the postcount increasing with a quote from the mailing list:


From: Tom Hacohen <>
To: Enlightenment developer list <>
Subject: Re: [E-devel] Enlightenment Tiling v2.0
Date: Tue, 04 Feb 2014 16:01:42 +0000

Hey guys,

I have a few updates regarding Tiling2:

Due to popular demand, the module is now external and in it’s own repo.
You can now easily compile it with your existing e19. It’s still e19
only, no e18 support.
Get it from:

A lot has been done since I’ve started it. There’s now a documentation
page on phab that lists what’s there, what’s not and how to use:

Only thing that I still need to do before considering it “1.0″ is
finding a way to easily promote/demote. I still haven’t found a proper
UX way of doing it. By that I mean, moving items up/down the tiling
tree. If you have an idea, please let me know.


by e-releasemanager at February 05, 2014 07:49 PM

~Jerome Pinot

SlackE17 0.17.6

I updated SlackE17 to 0.17.6. The tarball contains now the EFL 1.7.10. Users will not see a lot of changes, this is mostly a bugfix release. E17 got bump to 0.17.6. Packages are available for i486 and x86_64, arm will come soon. You’ll need a Slackware 14.1.

You can download SlackE17 packages or sources at the usual place on Sourceforge.

If you prefer to do an on-line update, you can use Slackpkg+ in order to install or update SlackE17. Once you installed Slackpkg+, just add one of this line to your /etc/slackpkg/slackpkgplus.conf


And then, activate the repository by adding ‘slacke17′ to REPOPLUS. You will have to run

# slackpkg update

at least one time before using slackpkg as usual.

by ngc891 at January 21, 2014 07:10 AM

~Andy Williams

Enlightened 2014

It was over 10 years ago that I started coding on Enlightenment, having discovered the window manager at Uni back when E 0.16 was what the cool geeks were using. The project was busy and full of excitement about the new libraries (EFL), the rewrite of the window manager for 0.17 and the many features this would provide. 3 years of fun coding later, many small applications and libraries and perhaps a heated debate or two and I somewhat lost touch with the project. Probably not coincidentally this was also around the time I moved to Mac and although it was possible back then to use a different window manager it was not without problems.

The years passed by and little visibly changed but at Christmas 2012 I heard that 0.17 had been released (over 10 years since we started developing it…) and it looked excellent. I slipped back into the habit of browsing screenshots, exploring what desktops could look like and what the EFL libraries provides these days. Dreaming once again of a geeks ideal desktop I realised how much Mac OSX had slowly removed flexibility and power features. But Macs just work and I was clearly productive using it.

That is until OSX Mavericks. The upgrade, whilst desirable for finally fixing virtual desktops, broke lots of other things. Mail doesn’t sync reliably with gmail and calendar has similar issues; the screen occasionally blanks then locks whilst in use and one day apps stopped launching altogether. I had to reinstall and create a whole new account to regain my computer – “just works” my foot. With such frustrations my reasons for being there were disappearing and I started thinking about realistic alternatives.

So back to exploring Linux, can it really be my full time desktop? Follow my explorations into Linux and the Enlightenment desktop in future posts.

Filed under: Conferences, Enlightenment

by Andrew Williams at January 20, 2014 11:13 PM

~Mike Blumenkrantz

App Development & Me: A Brief History With Infographics And Supplementary Readings As Well As A Look Into The Future

Fed up with the constant GTK3-related downward spiral of GMPC (which I have been using for 6+ years), last month I started writing my own music player. I know what you're saying:
Why write an EFL app which isn't an image viewer?

Well the short answer is...I didn't. It displays images. So don't worry about that. We'll come back to apps, but first let's take a look into some history.

I've written a number of EFL apps in the past. The thing is, mostly I just write them for my own use. I needed a photo viewer and XV wasn't available, so I wrote EV. I was linking lots of images in chat, so I wrote Shotgun and then started on its successor, S2, so I could have tooltips of all the gifs without needing to click them. I even wrote an RSS aggregating daemon, eRSSd, on a request with the intent to build a nice gadget around it, which I'll probably get back to sometime next year.

All these things have something in common: they were functional. I mean this in the sense of function vs. form--they served their purposes, but they didn't necessarily look great while doing it.

This is a bit of a problem, I suppose, given that I work so much with UI stuff while working on Enlightenment. People see that I'm writing an app, they know that there are very few EFL-based apps (Terminology, that other one, uhh...), and so they expect great things. Then I get a deluge of Gustavos saying "Hey nice app, kid, did you make it with TK?" While such things are always amusing, it seems like the idea of making "self use" apps which are moderately complex, such as an XMPP client, is Not Smart. Or at least, that's the idea that other people have tried to convey. I'm not going anywhere with this, it's my personal development blog so I get to ramble if I feel like it.

So that brings me to the present-ish. After the amazing people over at SRA were nice enough to take in a lowly release manager, I found myself with a small amount of both time and sanity to spare. Naturally, to fix both of these things I decided to write another app, and to make that app look good. Also I merged the 6+-month old E19 branch, creating $Texas bugs and causing me to spend well over 70 hours in the past week doing emergency cleanup.

Now that I'm writing another app, and a music player(ish) one at that, the obvious first question that most people would ask is "How should it look?" Amateurs. The first question I asked myself was "How can I massively overengineer this?" Those people who are in the know about my previous development history can probably guess the answer.

Empeedee, as I am calling the initial project, is a client-server package for MPD. "Why MPD and not XMMS2?" asked one random stalker. I use MPD. I've used MPD for almost 10 years, and I don't see myself ever not using it unless something similar-but-better is written. If I'm in a place where it's not practical to set up MPD, I use a piped mplayer for gapless playback. Look it up.

MPD has what I would consider a bit of a design flaw: it doesn't have any concept of subscriptions or PUSH data. This means that it's completely passive, only providing information/data when explicit requests have been made, and then only to the client which has made the request. If you're using a system and want to have updated information in a couple places, such as a gadget and an app, this means you've got to spam MPD with status requests multiple times a second from each client--hardly ideal even if MPD is able to handle a number of clients doing this simultaneously.

My approach was a bit different: create a daemon to do the connection to MPD, and then use DBus to interact with that and broadcast it to anyone listening. This reduces overall CPU usage since additional clients get the same data for free. Obviously this approach isn't as useful if you're only going to have one app running against MPD, but it does make writing that app much easier, I've discovered, since I can use autogenerated DBus bindings and keep everything asynchronous with ease.

Anyway, last month I started the project. This was the result (26 Dec 2013):
EMPC V1 - Widgets!
I use the darkness theme on my desktop along with its accompanying elm theme, which is why it's black instead of gray. And yes, I redid the slider theme after taking that shot.
Now this obviously isn't anywhere near a great-looking app. I wanted to get something functional and non-crashy in place before I took some time to work on aesthetics. Every element in the UI here is functional and works as expected, so that was a great foundation to start with.

I used EMPC daily after this point, mostly as a nice way to display MPD status in a smaller window on my IRC desktop since GMPC needs to be run fullscreen to be useful. Lots of things happened over the next month, and then I was struck by the need to get back to it over the past few days, possibly due to the arrival of the incredibly catchy Clear album by Periphery, which I'm looking forward to purchasing legitimately in a few days. Here's another shot from 18 Jan 2014 after a few hours of work and introducing some custom EDC:
The cover art just copies the GMPC/GLYR database (sqlite, vomit) info using Esskyuehl. I had a great time working with ESQL again after being away from it for so long, and it worked perfectly right out of the git with only one bug in the sqlite part itself. The extremely hackish module for getting this data is about 170 lines, 40 of which are lines of enums copied from GLYR and another 20 for the SQL query.
I spent some time experimenting with text here before arriving at the conclusion that it just wasn't going to be possible to display the playlist over the album art like this due to coloring. This album art was especially good since it was very light-colored, which caused my normal bright-colored text preference to fall on its face. Edje doesn't yet provide many options for outlining or related effects to make text stand out here, so I had to think of something else. Also there were still the gross widgets at the top to do away with.
Later the same day this happened:
EMPC V3 - What's that thing in the middle?
I've got a custom slider style in action at the bottom, and all the buttons have been moved offscreen. Artist/Album/Title/Track are now easily visible, and the current time is stuck in the middle because I hadn't figured out what to do with it then.
Less than an hour later:
EMPC V4 - Not noticeably different
This is basically the same as the previous version except that the alignment of the text and slider at the bottom is a little more accurate. I don't remember why I updated the screenshot.
At this point I had also really fleshed out the overlays:
EMPC V4 - Overlays open
This is actually two separate overlays: the bottom one holds the control buttons and moves up and down (pushing the slider and text with it), and the playlist is a scrolling 3 column custom genlist which slides in/out from/to the right along with the translucent underlay so the text is readable. Both toggle automatically based on mouse movements and also can be manually toggled by pressing F1, which is sort of the same as GMPC.
After more tweaking today, I finally ended up with something I'm moderately pleased with:
EMPC V4 - Overlays open, song selected
The time now displays and updates only on the overlay, which enabled me to remove it from the main screen. Also I added some super hacks to the slider to make it look super cool, though this isn't visible from a screenshot.

I've still got a lot to do here: the metadata fetcher needs to be an actual module instead of a compiled-in, repeat/consume/single mode toggle elements need to be added, and I should probably add file selection capabilities at some point so I can do more than just delete items from the current playlist without having to go to another client.

Based on this, I'd say that app development with EFL is definitely possible with the current libraries. Some of the more subtle animations that I wanted to do were tricky to implement, but none of this was anything that I'd consider challenging, so maybe others will be inspired to try working on their own EFL apps after reading these ramblings.

I should probably blog here more frequently, but I seldom work on my own projects any more so there isn't usually a lot to talk about.

by discomfitor ( at January 20, 2014 12:15 AM

Interesting stuff on E

Coverity Scan has Elementary at a defect rate of ZERO

According to Coverity we hit a major milestone today. Elementary now has a defect rate of ZERO. 0. NADA. That's something to be proud of. We still have to improve EFL and Enlightenment (EFL is at 0.52 and Enlightenment at 0.66). The average for "good quality commercial code" is 1.0, so we're doing well either way, but we can do better. Take Elementary as a lead.

And yes. Static analysis tools do not catch everything, and they often produce false positives too, but it's like having another set of eyes automatically review your code all the time pointing out potential issues, and that can only help improve the quality.

by raster (Carsten Haitzler (Rasterman)) at January 13, 2014 07:15 AM

~Brian Miculcy 1.6.2 released

This new version 1.6.2 added more checked dependencies and fixes a bug with updating from git. Update advised!

by Brian 'morlenxus' Miculcy at January 06, 2014 02:55 PM

~Jerome Pinot

ePeriodique 0.5

With the release of the EFL 1.8, I had to check my applications for any compatibility issues. In theory, there should be no problem in code and it’s pretty much true: if your application runs with efl 1.7, it should run as well with 1.8 because the API didn’t break. And that’s nice.

However, there are some pitfalls. One of these is the strictness of EDC code ordering. For instance, in your edje file, the target must be after the transition in EFL 1.8. Something like that was working well with 1.7:

/* EFL 1.7 */
program {
signal: "mouse,in";
source: "Title";
action: STATE_SET "over" 1.0;
target: "Title";
transition: SINUSOIDAL 0.7;

But now, it has to be written like that for 1.8:

/* EFL 1.8 */
program {
signal: "mouse,in";
source: "Title";
action: STATE_SET "over" 1.0;
transition: SINUSOIDAL 0.7;
target: "Title";

It’s a really small change but pretty hard to find out.

If the code didn’t really change, the biggest adaptation to make is related to the new elementary theme. Switching from white background to dark grey is leading to readability issue if you chose some custom colors. That was most of the work I had to do to make ePeriodique happy with the new EFL. So here comes ePeriodique 0.5:

Main screen
Main screen

by ngc891 at January 02, 2014 03:43 AM