Enlightenment 0.17, the big, long awaited new release of the Enlightenment project, has been in the making for a long time now – since December 2000, to be precise. E17, as it became known, is a complete rewrite of Enlightenment, complete with a set of base libraries (the Enlightenment Foundation Libraries) turning it into a full-fledged desktop environment, complete with its own set of base libraries for building applications. Last November, main developer Carsten ‘Rasterman’ Haitzler stated that there were only two big to-do items left blocking the release of E17. We’re now a few months ahead, so I contacted Rasterman to see what’s what.One of those two to-do items was a new theme. The theme E17 currently uses has served E17 well, but also looks a bit outdated, and a bit over the top; it was made to show off what E17 could do, and as such, it was full of bling-bling – and, according to Rasterman, it was “not incredibly popular” either. The new theme, currently in the works by Rasterman, aims to be a bit more conservative. There is a screenshot of a new theme on Rasterman’s webserver, so I asked him if that was a work-in-progress for the new theme he mentioned.
That’s real. I haven’t had much time lately to work on it, but it’s moving along. Gadgets are done now. I need to get started on widgets and other elements. A theme is no small task. Well, there are 3 items – theme, filemanager and wizard – major items. Lots of minor ones, too.
The new theme indeed appears to be less bling-blingy. It’s more subdued, and not as – my apologies – tacky as the gold one. The combination of white and black makes it a lot less intrusive, and other applications will blend in much more easily than with the gold theme. Please note, though, that this is still very much a work in progress, so what you see is subject to change.
Last week, Rasterman announced the release of Eet 1.0.0, one of the relatively minor Foundation Libraries. “Eet is primarily a data encoding, decoding and storage library. It is meant to be very programmer friendly, removing lots of work from loading and saving data held in data structures. It can store multiple chunks of data in a single file and random-access retrieve the data very efficiently, encode and decode image data and any other kind of data. Files are compact and efficient as well as being portable between platforms.”
Seeing Eet is one of the first EFLs going 1.0.0, I wondered if this was the first sign of an upcoming final release of E17. When asked, Rasterman replied, chuckling: “No comment. We released version 1.0.0 of Eet because it’s solid, stable, and ready for 1.0.0.” That’s quite the clear answer. He added: “You should know I won’t say anything!”
Of course, I had to ask the inevitable question: does Rasterman have any timeframe in mind for the release of the final version of E17? His reply was to be expected – “No comment.” Smiley face included. The big blocker right now is a lack of time, Rasterman said.
Do not let the lack of a final release fool you into believing E17 is currently not ready to be used. It has its stability issues every now and then, but overall, it is very much usable – as evidenced by the fact that some Linux distributions (such as Terra Soft’s Yellow Dog Linux, and gOS) use E17 (or some of its components). Using E17 takes a bit of getting used to, as it does a lot of things just that little bit differently than most others, but overall, the experience is already there. What needs to be done is – indeed – design a more up-to-date look, and polishing of the rough edges. In addition, I’d personally love to see more “native” applications that use the EFL, most notably an email client.
Been waiting for E17 for a very long time, one of the first window managers I ever became comfortable with was E16 but it wasn’t long before it was passed up by the other full desktops. I’m sure many will disagree, but I feel like with the work that’s been thrown behind Gnome and KDE recently that E17 is losing it’s relevancy. Maybe my idea of who the audience that E17 is targeting is out of date, anyone have any idea what that might be today?
Edited 2008-04-24 21:28 UTC
I’m sure many will disagree, but I feel like with the work that’s been thrown behind Gnome and KDE recently that E17 is losing it’s relevancy.
I agree. I think it’s been so long coming that die-hard Enlightenment users have long since switched to other window managers or desktop environments. E17 is going to have to win over a whole new set of users. That means there is going to have to be some significant advantages over other environments in order for it to gain any mindshare in today’s FOSS world. I guess the best thing E17 has going for it now is its relatively small footprint.
I think it also has to support aiglx (be a compitz alternative) to get attention.
Ironic really, as back in the old days, it was the high-end, bling-tastic desktop of choice for power users.
I used to use it 3 years ago (compiled from cvs), even back then it was quite stable. I stopped using it because it seemed to be going nowhere fast and after a while it was just easier to use gnome and kde.
I would say it is a good replacement for those who still use e16 and it is similarly lightweight in comparison to xfce (but prettier in my opinion).
I think though that they spent too much time faffing around with creating etk when they should have just used gtk and made an engine that is suited to e17. There aren’t enough apps that use etk and so the desktop is inevitably going to use gtk and qt based apps.
It has taken too long but there is little they could do about it short of getting more people to work on it.
Edited 2008-04-24 22:13 UTC
It doesn’t matter how good it is if it’s never released.
Release early, release often, or fade into irrelevance.
I used to be a diehard E16 user, now a GNOME (Dropline, to be precise) user, and I wholeheartedly agree with you. Judging from the scores you received so far, I know I am not the only one.
E17, is very solid. and its not just a simple window manager, it is more of a window mgr framework. Its first class, and already very stable.
I have made some comments on E17 on my blog ( http://nex6.blogspot.com/ )
just search for E17,
-Nexus6
…although I respect Enlightenment as a DE (compared to the other bloated ones), I’d rather have Openbox as my WM. Speedy, lightweight and does what it’s supposed to do, no more, no less. 🙂
is great! the bling theme is really inspiring and captivating to me, but I’ve been using the new theme by default for over a month. raster hosts it on his page.
http://www.rasterman.com/files/new.edj
enjoy fellow Eheads
Screenshot please?
http://i131.photobucket.com/albums/p312/scottied16/newtheme.jpg
screenie of my lapytappy
e17 ftw
Edited 2008-04-25 01:50 UTC
I was using E17 back when you could have widgets all over the desktop, not just on the dock. I dont care for how your now locked in to have them just in the dock, but i will admit, even on my older 700MHz PC with only 256 MB Ram, I run Ubuntu with E17 as the default, and it does run pretty swiftly.
Swiftly compared to what?
I recently used Ubuntu on a 1GHz with ~700MB RAM and that wasn’t very funny. Productivity really suffered mostly because of the GTK UI itself. Even typing was lagging in applications like Eclipse.
Now I use a 1.6GHz P4 at “work” with 1.2GB RAM and while it’s a bit better, it’s still quite slow, especially browning with Firefox. Also the System Monitor takes up 30% CPU by itself making it unusable.
Both computers run Windows 2000 without seeming slow.
But I have experienced this for years with a whole lot of old computers so it’s nothing new.
Something is fundamentally damaged within the X, GTK or whatever code or design that slows Linux computers down tremendously (for GUI work).
Or perhaps something is fundamentally damaged with your computing skills. Running Ubuntu on a 1.3Ghz laptop with 512Mb is quite swift (I’m using it right at this moment) and even more so on a 1.6Ghz C2D with 1Gb.
Not that Windows is slower, it’s pretty much the same speed-wise with XP although Vista is certainly more sluggish.
Nope. I have been getting the same performance issues that the grand poster describes with GNOME on older machines and I have been saying this for years: GNOME and GTK+ are both really slow compared to most other DEs and toolkits and the fact that X isn’t exactly a speed demon either does not help it. Ubuntu is slightly slower than some GNOME distros, though (with the possible exception of OpenSUSE). It could be some background service/daemon or some such, but it is definitely slower than even Fedora.
I’ll concede that it is less of an issue on anything faster than 1Ghz and that the video driver will certainly affect your perception of speed on the GUI side of things but if performance is a concern, you’re better off with other distros such as Slackware or Debian proper.
But hey – I am getting used to it already: go ahead and tell me that there is something wrong with my setup and that Ubuntu is most likely the fastest distro on the planet (and the best that there is, while we’re at it!)
Uh?
Why should it be the lower level library?
Me I tend to think that it’s caused by lack of multithreading, but this isn’t a lower level library issue more an application design issue..
[ I’m running Linux at work, Windows XP at home, *both* sucks in responsiveness compared to what BeOS provided quite a few years ago ]
You, my friend, ran into a rather serious bug in GNOME System Monitor-and btw it has already been fixed.
http://bugzilla.gnome.org/show_bug.cgi?id=507797
The guys working on that software decided to make some really nice snazzy graphics for displaying system information-unfortunately these graphics brought most machines to their knees.
This has now been fixed,probably not perfect yet-but significantly less CPU usage, and most distros should be offering an update.
It still sucks that when programmers use the prefered API’s to make nice graphics, that these API’s are only as good as the driver support. In this case cairo was used to create the snazzy graphics and cairo uses RENDER, which unfortunately is not very well supported by many graphics card drivers…
But this bug, at least, has been redressed.
In this case cairo was used to create the snazzy graphics and cairo uses RENDER,
That is one of the things I don’t quite understand. OpenGL is REALLY well supported under Linux, it is a lot faster than RENDER and Cairo does support it via glitz…But still no one uses it. Why? It should be quite trivial to make f.ex. a control center applet that checks if OpenGL is enabled and allows you to test if Cairo with glitz works properly and then sets a gconf setting that globally enables or disables that. Would provide a nice performance boost..
The description remind me of one of the KDE4 feature paln long time ago. There was a plan that integrate small configuration files into one big one to improve performance. Can KDE developper use Eet to archive this?
It’s called a registry, and experience says it’s generally a bad idea.
At least that was my impression when I first heard about it ~10 years ago. “Enlightenment”, not only nice looking/etc., also the name has “deep meaning” or something
Too bad I’m not sure why I’d use it today…perhaps on OLPC XO-like machine, instead of XFce? But it would have to be faster (is it?) – somehow I doubt it’s on par with XFce feature-wise, and if I’d settle on using something more minimalistic, I might as well go with _really_ light WMs…