I’ve been hearing a lot of grumbling and complaining from users over the past few weeks about how “E18 release is taking so long!” and “E18 doesn’t have all the features that it should” and “E18 burned my coffee!”.
There was a comment (not-so-)recently which asked what the motivation and main features of E18 were supposed to be, which brought it to my attention that we had no public roadmap or timeline, and my blog is basically the only interaction that exists between the general public and E18. I’m going to take some time to break this down:
This is a list of the core features which, just as WINE does, were/are the criteria necessary for the release of E18 as well as the motivation behind it.
- Compositor integration, improvement, and usage.
In E17, a compositor module existed. It was written a few years ago as a basically a proof of concept and a demo of a composited E desktop. There were lots of bugs, and it did basically nothing aside from 1) composite your windows, 2) draw shadows, 3) add some subtle effects. E18’s primary goal was to make the compositor not only better in every way, but mandatory.
“Why should compositing be required?” is a frequently-asked question here, and one that I’ll be answering on the E19 blog in a future post, since that will focus almost exclusively on the topic of compositors. The really short and simple answer is “Because it looks nicer”. Anyone not satisfied with this answer has the choice between two alternative answers: “Because it makes things faster in some cases” or “Because it makes development much, much, much easier”.
“In making compositing a requirement, what’s been done here to make it worthwhile?” is another common question. The answer is as follows:
Canvas merging. This was the biggest and most time-consuming part of E18 development, and it took nearly three months to effectively execute. In E17, everything drawn by the window manager, excluding shelves which were set to “Below everything” had X windows and separate canvases backing them. This meant that every time you opened the menu, saw a popup, or made the gadget overlay visible, you were waiting for and using additional X resources, not to mention the resources required to create and render to a new canvas. In E18, the only visuals which have X windows backing them are the compositor itself and any internal settings windows you may open. Everything else, from popups, to shelves, to gadgets, to menus, to overlays, is drawn directly onto the compositor canvas.
Bugfixing. Lots, and lots, and lots, and lots, and even more than lots, of bug fixing. The E18 compositor runs faster, more smoothly, and using fewer resources than the E17 compositor. It’s also more accurate, which is easy to see if you scroll back and forth over a GTK application’s menu bar quickly.
Eye candy. We went from having choppy, limited desktop transitions, which actually required display server protocol interaction, to having around twice as many silky smooth animations which only rely on the speed and resources of the canvas that we’re drawing on. Additionally, it has become trivial to write and configure custom animations for this, as I outlined in a previous post. More things like this are on the way, and it will be a big part of E19.
Wayland support. A non-composited desktop does not exist in Wayland, so this was a fundamental incompatibility which had to be fixed because, as everyone knows, Wayland and HTML5 are the future.
The downside of such a huge, fundamental change in a window manager (which still has code in it that’s 10 years old) is that it was all done as carefully as possible with as few changes to the surrounding architecture as necessary. This means that there is still a huge amount of code duplication and unnecessary latency in many areas. Is it noticeable to the user? No, since so many other things have been so heavily optimized. But to put it in perspective, E19 currently, before optimization has begun, starts over 25% faster than E18.
- UDisks2 support.
I caught a lot of flak from users for not integrating this before the E17 release, and that’s not unexpected; E17 release was difficult and painful, and really we just wanted to get a release out there so we could have a starting point to add features. It was always intended, though it took a bit longer than expected because I am only one man, for E18 to support UDisks2 and stop requiring the now-very-old UDisks1. There’s not really a lot to say here since it’s a pretty self-explanatory feature.
- Eye candy.
In the XComposite protocol specification, there is a special thank-you note for Carsten “Rasterman” Haitzler, for “Enlightenment, the original eye-candy window manager”. We hadn’t done anything truly groundbreaking in a while with E17, so it was always going to be the case that E18 should start to get us off the bench and back into the game here. We’ve got a long way to go in terms of [what we’re doing] vs. [what we’re capable of doing], but some of the intended changes are going to take time, since they require architectural changes to the underlying subsystems to better accommodate them.
One user, who remarked recently that “parts of [E18] still look like they’re from 2006″ has no idea how accurate the statement is; checking code history will reveal that a staggering amount of code is at least that old. This isn’t necessarily a bad thing, since the design and implementation were sound at the time, but EFL and OSS have come a long way since then, and there are different and better ways to implement some things now. These changes, however, are going to take time, because we are, surprisingly enough, striving to make releases a fairly regular thing. My ideal timeframe for some releases could be as much as a full year, and other times as little as six months, but these scales will depend heavily on what features are slated for the release. A release with fewer or smaller features takes much less time to implement and stabilize than one like E18, which has (what I would say is) lots of new, complex features.
And that’s it. It’s not a huge list of features, but it resulted in a pretty large amount of code churn for one person to manage.
I think this sums things up effectively. We were planning on doing EFL 1.8 around the start of July. E18 depends on the EFL 1.8 release. Since the 1.8 release was delayed, this means that the E18 release is still pending. I have no dates to give out now, but I’ll point readers to this event and suggest that there is a history of announcing releases of E-related things at LinuxCons.
Another factor in the lack of releases is that I’m required by EFL policy to delay the release by a week every time someone asks me when the release date is. I’ll also quote a great author by saying that “[E18] is not your bitch.”
EDIT: Just to make things clear, E18 will not be Wayland-only. There will be Wayland support.