Enlightenment DR 0.21.2 Release (The slightly lazy release)

Posted on August 25, 2016 by Simotek

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.

https://www.enlightenment .org/news/e21_release
https://www.enlightenment.org/news/e-0.21.1-release
https://www.enlightenment.org/news/e-0.21.2-release

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

Posted on June 8, 2016 by Simotek

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

http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.9.tar.gz

48259584b77a9549a412f942cfeafad127ab3b60710c3118297397444be0deaa

http://download.enlightenment.org/rel/apps/enlightenment/enlightenment-0.20.9.tar.xz

db792ad4d97b2523ff0bfc2c911bb3fea4b1eda60400871f4b78bc3ae2f1d1be

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

https://git.enlightenment.org/core/efl.git/tree/README
https://git.enlightenment.org/core/elementary.git/tree/README
https://git.enlightenment.org/core/emotion_generic_players.git/tree/README
https://git.enlightenment.org/core/evas_generic_loaders.git/tree/README

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

Help my menu keeps running away

Posted on May 27, 2016 by Simotek

The latest blooper from the world of enlightenment beta testing.

Toolkit Focus

Posted on May 23, 2016 by bu5hm4n

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.

Examples:

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

Sphaira

Posted on May 20, 2016 by e-releasemanager

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.

Passing The Torch

Posted on May 17, 2016 by e-releasemanager

As I wrote on a mail last week, I’m passing stable release management over to Simon Lees, the OpenSUSE Enlightenment package maintainer. He’s just punted his first release. Thanks Simon!

Re

Posted on May 6, 2016 by e-releasemanager

https://blogs.s-osg.org/recovery-journey-discovery/

Wreath

Posted on April 26, 2016 by e-releasemanager

Release day!

https://www.enlightenment.org/news/e20_7_release

https://www.enlightenment.org/news/e21_beta_release

The Perfect Element

Posted on April 21, 2016 by e-releasemanager

I’ve been deep within the compositing mines, harvesting new pixmaps for the coming dry season. In the past week or so, the following things have happened:

Chris merged a new libinput abstraction library (“elput”)
Derek merged client-side DMA buffer support
Wayland DnD got upgraded to v3 and fixed again
The extremely long-lived Chromium-based tooltip browser bug was finally slain in Enlightenment
Startup applications now work in Wayland
Window placement algorithm fixed to work with multiple monitors