Category: EFL

  • 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
  • October 14, 2016 - Marcel Hollerbach

    Samsung OSG Internship Program: Marcel Hollerbach

    My name is Marcel Hollerbach, and I’m the second intern to join the Samsung OSG as a part of their Enlightenment internship program. I wanted to take a moment to introduce myself and provide some background about how I got started in EFL development, and I’ll also explain what I’ll be doing as a part of this internship. My Path Towards EFL Development Currently, I’m studying Computer Science at the University of Karlsruhe, but I learned programming a while back by starting with Java. My interest eventually brought me to C and C++, and in 2011 I was first introduced to Enlightenment and EFL. A year later I discovered terminology: a great EFL-based terminal emulator; this led to me making the decision to learn to code with EFL. I began by attempting to write the wallpaper settings for Terminology, which is essentially a screen that can be used to select […]

    Read More
  • October 7, 2016 - Chris Michael

    Introducing the New & Improved Ecore_Drm2 Library

    In the early days of developing Wayland support in EFL/Enlightenment, it was quickly apparent that EFL would need an abstraction library to interface with libdrm. We wanted users of EFL to be able to call simple functions without having to know about the underlying internals of libdrm, thus the original Ecore_Drm library was born. First, efforts to develop this library were undertaken with much enthusiasm and little fan-fare. After the birth of Ecore_Drm, we then proceeded to integrate it’s usage into some new Evas and Ecore_Evas engines so that the Enlightenment Desktop Shell could make use of it and render our first standalone Wayland desktop implementation. After kicking the tires of our Wayland desktop for a while, we came to realize some shortcomings of the existing Ecore_Drm implementation. For starters, it would create it’s own Ecore_Drm_Device structure when launching the Enlightenment Wayland desktop (this structure was a representation of the […]

    Read More