Category: EFL

  • November 3, 2017 - Mike Blumenkrantz

    New Features in Enlightenment 22

    The E22 development cycle has been underway for over a year, and it has included over 1,500 patches to address nearly 200 tickets on our issue tracker. With this has come a number of new features and improvements. Greatly Improved Wayland Support The majority of development for this cycle has gone towards improving Wayland support. This covers, but is not limited to: adding support for xdg-shell v6, pointer constraints, and relative pointer motion protocols. These additions improve XWayland support and increase stability across all components running under Wayland. Continued Improvements to New Gadget Infrastructure As previous posts have indicated, a lot of work is being done in this area. The goal is to create a more robust infrastructure with a simpler and more intuitive EFL-based API, moving away from the legacy “gadcon” interface, which has its own API and currently only functions due to mountains of gadget-specific workarounds that make […]

    Read More
  • October 5, 2017 - Mike Blumenkrantz

    How to Create an EFL Gadget Sandbox

    The new gadget API and infrastructure for Enlightenment continue to undergo heavy development. In addition to improving and extending the base gadget UI, work has recently begun on creating a gadget provider with the new API to provide sandboxing and allow gadgets to be written as regular applications that don’t have or require access to compositor internals. The primary enabler of the new sandboxing system is the efl-wl compositor widget. This allows the compositor to launch applications in isolation, and also provides the ability to add protocol extensions for only that specific instance of the compositor widget. Using these features, it becomes possible to add gadget-specific protocols and utilities on the compositor side that are passed through transparently to the client gadget application. Currently, there is one base protocol in use: the e-gadget protocol, which looks like this:

    The purpose of this is to mimic the gadget API. Applications […]

    Read More
  • Wayland: there have been many blog posts, articles, and news items about the new Linux display protocol. There have been developers working to extend the protocol for new and extremely helpful use cases, but new frontiers continue to be explored: putting a multiseat Wayland compositor into a toolkit widget. Due to Wayland’s philosophy of “build your own compositor,” there is no de-facto implementation of a Wayland display server that is analogous to Xorg for X11. Wayland implementations are written using the libwayland server API, and this is flexible enough to be used even in the case of a widget. Overall, the only noteworthy difference between putting a compositor in a widget and a normal nested compositor is that the output size is set to the size of the widget instead of the size of the window. With this in mind, a compositor widget can be manipulated just like any other […]

    Read More
  • Recent development in Enlightenment’s Wayland compositor has focused on implementing cross-desktop protocols and improving stability. One of the recently handled protocol series has been relative and constrained pointers. Relative pointer motion is a method for providing pointer movement deltas directly to applications. This is useful for a number of cases, though the easiest to imagine might be first person shooter games. In this case, the application receives movement deltas, allowing the player to endlessly scroll the screen in one direction without hitting the boundaries of the screen. Under Enlightenment, this is handled in different ways depending on the output backend being used. For backends using libinput, e.g., DRM, it’s possible to get relative motion deltas directly from the events and then emit them for compositor use. Other backends, however, such as nested Wayland compositors, have no access to libinput’s hardware events. In this case, Enlightenment must manually calculate the deltas […]

    Read More
  • I want to use this short article to point out a big problem in code that uses libdrm. This, or a variant of this, is lurking in a shocking amount of software:

    Stop doing this, it has always been a crash waiting to happen. drmEventContext is part of libdrm’s ABI and there are strict promises that the structure won’t be randomly re-ordered. However, it may grow as the need arises when new versions of libdrm offer functionality which didn’t exist before. libdrm 2.4.78 introduces another page flip handler, adding a new function pointer harmlessly at the end of the structure page_flip_handler2. It also bumps DRM_EVENT_CONTEXT_VERSION from 2 to 3, as that’s the current version of the structure in the header file. As a result, the code above crashes… sometimes. What went wrong? The Proper Way to Use drmEventContext DrmEventContext.version is intended to tell the library what version of the […]

    Read More
  • February 2, 2017 - Derek Foreman

    A Curious Wayland Bug

    Enlightenment has a slightly unconventional architecture. For many of its internal dialogues (settings, the file manager, etc.) it uses what we call “internal windows.” These are simply regular toolkit windows that use regular rendering back-ends; in the good ol’ days, this meant a connection to the X server which resulted in a render to a standard X window. In this scenario, the compositor gets the result back the same way as all X client windows, and it composites all internal and external windows together. Under Wayland, things get a bit scarier because now the compositor is the display server. Enlightenment makes a Wayland connection to itself; this gives us all manner of game winning capabilities we never had before. For example, let’s say the internal window wants to sleep and wait for a reply from the compositor (such as a released buffer to render the next frame into). We deadlock and fall down […]

    Read More
  • While there are some developers who are familiar with using Ecore_Evas to create a canvas for applications, we often find that new EFL users face some confusion when first trying to create an application. This article aims to provide a simple example of how to create your first EFL Wayland application. For those not familiar with the Ecore_Evas library, it is a set of functions that make it easy to tie together Ecore’s main loop and input handling to Evas; as such, it’s a natural base for EFL applications. While this combination makes it easy to create the basic aspects all applications need, for normal applications (those that use buttons, checkboxes and layouts) one should consider using Elementary. Ecore_Evas is extremely well suited for applications that are not based on widgets. It has a main loop that delivers events, does basic window handling, and leaves all of the drawing up […]

    Read More
  • December 12, 2016 - Cedric Bail

    New Improvements to EFL Animation Management

    EFL is undergoing a huge API refactor; the goal of this change is to simplify API usage while simultaneously making it more powerful. One major component that required improvement was animation management. Legacy In the past, Ecore_Animator was the only object in charge of providing information about when to animate something; this had a few limitations and problems. The first problem is handling the lifecycle of the object: it must be manually destroyed once the animation is completed or when the object that uses it is destroyed. There was no way to link the object lifecycle with another object in any way or form. The animator object was built with the idea that there is one, and only one, global frame rate for the entire application. This is becoming less true today as moving to Wayland provides the ability to get the animation tick from the compositor on a per-window […]

    Read More
  • November 17, 2016 - Marcel Hollerbach

    An Introduction to Managing Enlightenment Widget Focus

    In Enlightenment, a widget can have focus, meaning that once a key on a keyboard is pressed the events will be delivered to the focused widget, and the widget can then react to the event. For example, a text field will start to append the letter ‘a’ once the appropriate key is hit on the keyboard; once the key is released, it will stop appending the characters. In other words, the focused widget is the widget that gets attention from input events. There can be several reasons for a widget to get focus, such as when a user clicks on it. But, there are also use cases where the user doesn’t have a touchscreen or mouse, such as on a TV, and needs to rely on a remote to control the focus on the screen. There are six directions that provide an optimal method for moving the focus around in […]

    Read More
  • Ibar has been Enlightenment’s primary launcher for at least a decade. What it lacked in features it gained in simplicity. However, as Enlightenment has grown, ibar has seemingly stayed stagnant. I wasn’t surprised when Mike Blumenkrantz informed me this would be one of the focuses of my internship. From the depths of Enlightenment’s growling, starving stomach, Luncher was born. In my previous post, I gave an introduction to developing gadgets for Enlightenment using the new gadget API; I did so by converting an existing module to the API, and this preparation was one of the first steps in creating Luncher. Mike and I spent weeks on end discussing ideas for Luncher including both necessary and wishlist features. We kicked around ideas and shared visuals of what we would like Luncher to be, and we identified weakness in ibar that must be improved for Luncher. In the end, we determined a […]

    Read More