Tag / Enlightenment Foundation Libraries

  • 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
  • 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 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
  • The past week or so has seen a significant amount of progress in the gadget backend of Enlightenment, due in no small part to the constant poking and prodding from Stephen Houston: our newest Samsung OSG Intern. As he mentioned in his post, we’ve known each other for quite some time now, so mentoring him has allowed both of us to skip over most of the pleasantries and get down to the code. Establishing a Mutually-Beneficial Partnership This type of internship is certainly new to me; seldom do I get the opportunity to sponsor and mentor a member of the community who has already been a contributor for such a long time. Given that I’d been the only one to use the new gadget API released in Enlightenment v21, I was curious to see what others would think after spending some time developing on top of it; soliciting feedback on […]

    Read More
  • During my LinuxCon EU talk last year I briefly touched on the sparse semantic parser tool started by Linus Torvalds in 2003 (slide 7). While it might not be as powerful as other static analyzers I described, it still might be worthwhile to run on your code. Many distributions ship a sparse package already, which makes it easy to test. If not you might want to grab the latest tarball and build it yourself. Once you have sparse installed, running it on your code should be easy as it provides a build wrapper around the CC environment variable. If you do not have any special requirements for CC in your build setup you should be able to run sparse like this:

    Use Filters to Find What Matters Depending on your code, you might be overwhelmed by the amount of warnings and maybe errors sparse is producing. While you should […]

    Read More
  • After three month of pleasure and pain, version 1.14 of the Enlightenment Foundation Libraries has finally been released. This is the sixth release I’ve managed as well as the sixth release to follow our time based release schedule. How We Got Here We aim for two months of development and one month of final stabilization. This can get problematic if we find problems late in the process, so we allow for some leeway here regarding the final release. We try to keep the delay within a week, and for 1.14 we have been two days late while chasing some of the bugs we considered to be show stoppers. Setting such a short release cycle helps our users get quicker access to the newest features and fixes, and after 18 months of following this schedule, we seem to have found a good balance. To be successful with such a rapid release […]

    Read More