Slashdot Mirror
EFL 1.0 Is Finally Released
Lisandro writes "The Enlightenment crew has finally released the first version of the Enlightenment Foundation Libraries, which the E17 desktop is built on."
Adds reader mu22le:
"Among the Enlightenment libraries hitting version 1.0 are Eina (core data structure), Eet (data encode/decode and storage), Evas (canvas and scenegraph rendering ), Ecore (core mainloop, display abstraction and utility), Embryo (small virtual machine and compiler), Edie (GUI layout and animation), E_Dbus, Efreet (handling of freedesktop.org standards), and Eeze (udev wrapping)."
Getting it right can take a while -- a preview of the EFL libraries first appeared in 2004. Enlightenment has never stopped looking cool.
Some time ago there were hints & speculations that Samsung bada mobile OS might use some Enlightenment libraries. Considering how future Samsung Star-like handsets might shift to bada from "feature phone" flavor of Touchwiz UI (it's already quite close), how primarily such handsets represent recent touchscreen boom (except for very few atypical but highly visible and vocal places) - millions of people might perhaps carry at all times part of Enlightenment with them quite soon...
One that hath name thou can not otter
As a linux enthusiast, user and eye-candy lover what could i do with this? honest question, is this the core to build enlightment?
Slashdot ya no es que lo era!
E17, which depends on these libraries, has been out for...how many years now? It's in wide use, and even has a specialized distro or two based on it. These may be v1.0 libraries, but that by no means indicates that they're "the first version". That's as silly a claim as the notion that v1.9 should be followed by v2.0 rather than by v1.10. The v1.0 appellation suggests that this is the first feature complete release, not the first version!
Just thumbing through these, this framework looks a lot like GObject... Why are there literally 5 or 6 different frameworks in Linux, each with their own container classes, marshaling, runloop, event handling, and string libraries again? It'd make sense if they were all for different languages, used vastly different semantics, etc. and then only barely, but these all have bindings for dozens of languages and all gab with the client in essentially the same way. It's weird.
Don't blame me, I voted for Baltar.
In retrospect, I've got to admire the dedication and self-control demonstrated by the E developers.
Back when E17 was started, it was a bloated (if awesome) project. I got sick and tired of waiting for it to finish, and pretty much soured on it when they started changing things drastically, making components (like efm - the file manager component of E17 at the time) discontinued. Granted, that's partially to be expected, but it was in development for years at that time - and reasonably stable despite.
Flash forward to now: it's a very, very lightweight window manager (compared to many others, at least) with a fairly rich featureset. It's been used recently on the "ePC" (2 years ago?) and IIRC it's been used on phones. The libraries are featureful and there is quite a lot of functionality exposed in the interfaces for the size of everything. The windowing toolkits are fast, and the result on my screen is likewise fast (and smooth) - even without acceleration. The libraries themselves are basically like the fltk2 toolkit, in many ways - but significantly more 'polished'.
It may have taken 10 years to 'get right' (or close to it) but the end result is, frankly, quite impressive.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
It's these version numbers that are confusing people. And everyone does these version numbers differently. So should we replace version numbers with dates? That would bring up other problems like should it be yyyy-mm-dd or mm-dd-yyyy or dd-mm-yyyy? Another way of doing this would be to have a feature complete indicator followed by a patch number. So you could have FC1.675. But others may want to use different structures or designators. We should all find a standard we can agree on mostly, and use that. But that can be like hurding cats.
Since they are graphical libraries a series of screen shots detailing what they are capable of wouldn't be too bad.
I think it's a fair question to ask if you want to dedicate some time into using them.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
If they want to promote a product that's essential to the UI of a desktop/handheld OS then why is their official site pretty much devoid of full-size images to give visitors a first impression?
Will the HURD finally be completed? Mass hysteria!
I am a former openmoko user. I developed openmoko apps using EFL as well. There is a lot of stuff missing from EFL. A lot of stuff which is not documented. There are many situations where you just have to try something and if it doesn't work, try something else. A good component set will have documentation telling you what components can be embedded in other components. In many cased with EFL you have to go to the code or write a test to find out. Interoperability between components seems to have been developed on an "as needed" basis. A lot of the error messages written to stdout are unprofessionally written and uninformative. Its easy to generate a crash. I just can't see this going anywhere.
http://michaelsmith.id.au