Category: EFL

  • 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
  • November 9, 2016 - Michaël Bouchaud

    Samsung OSG Intern Profile: Michaël Bouchaud

    My name is Michaël Bouchaud, and over the years I’ve been a software developer with several companies; I’ve now become the most recent intern in the Samsung Open Source Group internship program. In this post, I’ll share my new activities, but first, I’ll introduce myself. How I Got My Start I’ve used Enlightenment since E16 was my desktop window manager while I was in high school. What attracted me to this environment the most is the fact that it’s lightweight and sits on the side of the interface, allowing it to be effective on both mobile and desktop. I was always a rather good math student, and I studied computer science, mathematics, physics and chemistry at university. At the end of my studies, I looked for work primarily in a Linux environment; the search was not easy, but I came across Substantiel, a little French company that works with Debian. It […]

    Read More
  • November 4, 2016 - Chris Michael

    Ecore_Wl2: An EFL Library for Wayland Applications

    Throughout the years of developing Wayland support for EFL, few EFL libraries have had as much impact on EFL Wayland applications as the Ecore_Wayland library has. This library was one of the first to make it possible to truly run EFL applications in a Wayland environment. As the years progressed, it became apparent that Ecore_Wayland had some shortcomings; this blog post will introduce you to the replacement for Ecore_Wayland, called Ecore_Wl2. Ecore_Wayland’s Shortcomings While testing our first Wayland implementation, it became apparent that the initial implementation of the Ecore_Wayland library had some drawbacks. Publicly exposed structures could not be changed easily without breaking existing applications, and any changes to existing Wayland protocols would require significant changes to our Ecore_Wayland library. It was also discovered that when an EFL Wayland application creates a new window, the backend library also creates an entirely new display and connection to the Wayland server. This […]

    Read More
  • October 26, 2016 - Chris Michael

    Ecore_Drm2: How to Use Atomic Modesetting

    In a previous article, I briefly discussed how the Ecore_Drm2 library came into being. This article will expand on that article and provide a brief introduction to the Atomic Modesetting and Nuclear Pageflip features inside the new Ecore_Drm2 library. What Makes Atomic Modesetting and Nuclear Pageflip so Great? For those that are unaware of what “modesetting” is, you may read more about it here. Atomic Modesetting is a feature that allows for output modes (resolutions, refresh rate, etc) to be tested in advance on a single screen or on multiple outputs. A benefit of this feature is that the given mode may be tested prior to being applied. If the test of a given output mode fails, the screen image doesn’t need to be changed to confirm a given mode works or not, thus reducing screen flickering. Atomic/Nuclear Pageflipping allows for a given scanout framebuffer object and/or one or more hardware […]

    Read More