Mike Blumenkrantz

Mike Blumenkrantz

About Mike Blumenkrantz

Mike is the release manager for Enlightenment as well as a core developer of the EFL toolkit. He sometimes contributes to the Servo application embedding API/ABI, and in his free time he attempts to write desktop applications.

  • Projects

    EFL, Servo
  • Role

    Senior Staff Engineer

Posts by Mike Blumenkrantz

  • 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
  • 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
  • September 16, 2016 - Mike Blumenkrantz

    Announcing the Samsung Open Source Group Internship Program

    Today, I’m switching gears from my usual technical posts to introduce a new initiative that we’re rolling out at the Open Source Group: the OSG Internship Program. Since the start of our team in 2013 we’ve been involved in a number of projects in different areas of the open source ecosystem. In the process we’ve come across a number of great community members, but we’ve also realized that our team isn’t large enough to tackle all of the technical challenges that we’re facing in the open source projects we work on. At Samsung, we greatly appreciate the collaborative nature of our relationship with these communities, and all the more so since many long-term contributors are hobbyists and students. Our appreciation runs deep for contributors who are working in these communities on their own time, particularly those who work collaboratively with us as we are preparing for future products. From time […]

    Read More
  • September 8, 2016 - Mike Blumenkrantz

    How to Create an Enlightenment Module

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. Module writing is one of the primary ways to expand the functionality of Enlightenment. By dynamically loading modules, the compositor is able to import code that has access to most Enlightenment internals. This allows developers to modify the desktop environment in nearly any way they can imagine, from new gadgets to compositor effects. This article will take a look at the basics of creating an Enlightenment module. The first part of creating a module is setting up a .desktop file for it. This allows the module to be visible for users within the module configuration dialog. An example file looks something like this:

    The ‘Name’ is the user-visible name of your module, and the ‘Icon’ is the filename of the .edj file which accompanies the module. The ‘Comment’ field provides supplementary information […]

    Read More
  • August 30, 2016 - Mike Blumenkrantz

    Enlightenment Gadget Lifetime Management & Site Creation

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. The previous tutorials covered the basics of gadgets, this article will explore some of the more complex aspects in more detail, specifically lifetime management and gadget site creation. Gadget Lifetime Management Gadgets are bound by two lifetimes: the gadget object’s lifetime, and the gadget instance lifetime. The gadget object is the visible display for a gadget and it is deleted when either the site is deleted, when the gadget instance is deleted, or when the gadget’s orientation changes. This lifetime can be tracked using the EVAS_CALLBACK_DEL callback on the created object. At the time of calling, this indicates that any memory related to the gadget object should be cleaned up, and any non-Elementary sub-objects should be deleted; the toolkit will not delete these automatically and they will leak without manual deletion. Once this […]

    Read More
  • August 23, 2016 - Mike Blumenkrantz

    How Enlightenment Gadgets Handle Sizing

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. This tutorial will provide further detail about aspects of Enlightenment’s new gadget system. Specifically, it will explore how sizing works in different contexts and how simple sizing policies can be leveraged to provide the best view of a gadget. Let’s start with the basics: what is sizing and why does it matter? Gadgets work a bit different than typical application widgets where one would simply pack them into a layout or use WEIGHT and ALIGN hints to fill portions of available regions. A gadget site uses an automatic sizing algorithm to fit itself into its given location. This ensures that gadgets are always the size the user has specified while also maintaining the best sizes for the gadgets so they will look the way the author intended. Finally, it also greatly simplifies the […]

    Read More
  • August 18, 2016 - Mike Blumenkrantz

    An Introduction to Enlightenment Gadget Orientation

    This article is part of a series of tutorials about Enlightenment: a compositing and stacking window manager. This tutorial will discuss gadget orientations. Orientation is a core concept that’s vital to understanding how a gadget will be displayed to the user, and it can improve the look of gadgets while also simplifying various parts of the code. In this context, orientation can be thought of as hints the gadget owner provides to the gadget that can be used to provide a more specific view of the gadget, based on it’s location. There are two components to orientation within the gadget system: the orientation enum and the anchor enum. Here is the orientation enum:

    This indicates the axis on which gadgets are positioned. In a horizontal taskbar-style layout E_GADGET_SITE_ORIENT_HORIZONTAL is used, whereas E_GADGET_SITE_ORIENT_VERTICAL would indicate a vertical layout similar to the bar style in Ubuntu’s Unity environment. E_GADGET_SITE_ORIENT_NONE is different; […]

    Read More