Enlightenment DR 0.21.2 Release (The slightly lazy release)

So Mike and I have either been

a) Lazy

b) Forgetful

c) Unable to read a todo list

d) All of the above.

And since any of us have posted here last there have been several releases (including a feature release), which has me wondering, if we make a release and know one hears it did we actually make a release at all? Either way here’s a release or 3 and your hearing about it so it must of happened.

Rather then listing everything (everything is an aweful lot after all) there’s a link to the news announcements¬†below and here are some of the highlights of e21 .

  • Greatly improved Wayland support
  • New gadget infrastructure
  • Wizard improvements
  • Video backgrounds

e21 is also a longer term supported release so regardless of when e22 will be released (one of the grand mysteries of this age) e21 will continue to receive bugfix releases until the end of 2017 and will receive releases for any critical issues throughout 2018 this makes it ideal for ¬†“Stable” Linux distro’s to pick up.

as always stay tuned to this blog for infrequent (well occasional at best) updates on enlightenment’s development

Your friendly stable release manager Simon (Simotek) Lees.

Enlightenment DR 0.20.9 Release

This bugfix release improves on the 0.20.8 release and resolves a number of issues.

== Tickets Addressed ==

* https://phab.enlightenment.org/T3277
* https://phab.enlightenment.org/T3555
* https://phab.enlightenment.org/T3654
* https://phab.enlightenment.org/T3681
* https://phab.enlightenment.org/T3683
* https://phab.enlightenment.org/T3701
* https://phab.enlightenment.org/T3702
* https://phab.enlightenment.org/T3716

== Changes ==
Carsten Haitzler (2):
e start – no it doesny need dbus-launch
e – suspend.hibernat intelligently – dont account for ac power

Chris Michael (2):
stop filling logs with buffer transform/scale spam
change ‘if’ clause to make gcc-6 happy

Dave Andreoli (1):
enlightenment_open: correctly return the exist status code of the executed command

Hannes Janetzek (1):
just a small patch to make sure evry_hide does not get called synchronously from an Evry_Action

Massimo Maiurana (1):
Updating italian translation

Mike Blumenkrantz (13):
remove pulse sinks/sources from list before running cbs which access the list
fix e_place_zone_region_smart_cleanup()
add client util function for detecting popups, block popups in ibar/tasks
update README.wayland to include xwayland crash bug
update client remember on opacity change
use current zone for shelf config dialog
set x11 maximized window hint correctly on resize end
delete x11 mouse-in job when hiding the job’s client
use current zone when activating a client’s menu with the mouse
handle shaded state when receiving x11 configure requests
only block mouse-out callback for wl action clients if the mouse is grabbed
unset comp_grabbed flag before action client compositor ungrab
force mouse-in again during comp ungrab if client previously had mouse-in
As always, stay tuned to the latest infrequent E updates around here some place.

== Download ==





**Enlightenment:** for when you might otherwise find your life complete.

== 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):


**Note:** E20 depends on EFL **v1.15.2** or newer for X11 compositing and 1.17 for Wayland support.

Toolkit Focus

What is Focus

The attribute “focused” on a widget means that all none-mouse related events will be emitted at first on this widget. After that the not-taken events will be emitted down the widget tree.

There are 3 (and a half) possibilitys why a widget could get focus:

  • Click on the widget. For the case the config of elementary is set to the policy ELM_FOCUS_MOVE_POLICY_CLICK and someone clicks on the widget, the widget will get focus.
  • Mouse enters the widget. The widget will get focus when the mouse entered the coordinates of the widget. Also only happens if the config is set to the policy ELM_FOCUS_MOVE_POLICY_IN
  • There was a key event which wanted to move the focus. “Moving the focus” can be done into 6 directions. Right, Left, Top, Down, Next, and Previous. Right, Left, Down, Top will move the focus to a widget which position is relative to the current focused widget on the right, left, down or top -side. The directions next and privious are more bound to the workflow of a user on the current set of widgets. So for example, you are having a formular where you can enter new clients for a adressbook, you will see a screen with input fields for name, last name, adress, the input fields are not aligned like a table, so moving focus down is not going to work. Using the mouse all the time to get focus to the next text field sucks. So moving the focus to the next possible widget which is needed to continue the workflow is more what we want. This is what the directions are describing.
  • The last reason for getting focus is pretty trivial, when the ui is created and the window is shown, the focus has to start somewhere, if not users without a mouse are going to have a problem. So this is just a half reason, because some widget just need to get focus in the beginning.

What widgets should be focusable

In general widgets which are reacting on keyboard input should be focusable. But which widgets are really reacting on keyboard input.
Let me show you an example, a entry needs keyboard input to display the typed characters. Same for a scroller, since it wants to react on the page down/page up keys. So lets say we are having a entry as content of a scroller, and the scroller has the focus. Looking at the highlight it would look like the entry has the focus, since the scroller pratically consits out of the entry, but pressing “a-b-c-d-e-f-g-h-i-j-k” will not result in some displayed characters in the entry, since the keyboard input will be go to the scroller. We see this is BAD, the scroller should just react on keyboard input which is not used by the content.

With the assumation that content is focusable we can say that the scroller is reacting passiv on keyboardinput.

Now the usecase where the content is not focusable, for example a big image in a scroller. This would mean there is no possibility on using the scroller with keyboard input, Again BAAD! So we have some kind of hybrid here. For the case the content is focusable, its a passiv keyboard user, for the case the content is not focusable it is a active keyboard user.

To summerize:
We have four kinds of widgets, no, active, passive and hybrid keyboard using widgets.


  • Entry is a active-type widget.
  • Scroller is hybrid.
  • Checkbox is also a active-type widget, the logic of the widget react for example on enter and spacebar to toogle its state.
  • Containers like Box Table or Grid are just containers they dont deal with keyboardinput, so they are no-type


Teamwork v2 is out now, providing Wayland support and dropping the dbus dependency. Integration into existing applications should be significantly easier, so hopefully we’ll see some increased adoption over v1. More details and demos to come, expect releases next week.


Wayland Recovery: A Journey Of Discovery