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!
It may be enlightened, but can it immanentize the eschaton?
and how exactly do you take screen shots of libraries? this isn't a Desktop Environment, this is the back end. and a review would only be useful to developers who have to work with this stuff, as most user's wont directly interact with the libraries, they'll interact with Enlightenment DE (Desktop Environment) itself. And finally, if you are unsure of what this is, or why you should/shouldn't install it, i would recommend not posting on slashdot (and looking dumb) about it, and not downloading and installing them either. In fact, pick up a book on programming geared toward the GUI and maybe you'll understand what this is, and why its needed.
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?
It makes them easier to sort, otherwise you have to reverse the order and then sort.
For something like versioning it should certainly be yyyymmdd as that way if you have a directory full of enlightenment-yyyy-mm-dd.tar.bz2 name order == version order.
Nick
Well, you could go to PC Linux OS and download the e17 iso. Load it up on a VM and test it out.
how about the API documentation and some sample code?
Do you even lift?
These aren't the 'roids you're looking for.
Follow the links in the article. Its all there.
Sig Battery depleted. Reverting to safe mode.
On that note, does anyone have any recommendations for a distro to flop down to test this? I feel a bit lazy to go about doing the hard work at the moment. I did use it, YEARS ago - and I just cannot remember what distro I saw it on!
I'd rather not use PC Linux OS myself - in such case I'd rather use Debian or Ubuntu directly.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
Been using E since the late 90s ever since I saw it in Mastering Linux. Although getting E17 to work used to be a chore, I found it's much easier to install no a days. Got it running flawlessly on an i7, a Core2 Duo, and an ancient P2120 (Transmeta Crusoe @ 933MHz). The only thing I miss is Entrance (Login Manager) :(
Cheers to Raster and the E-Team!
Even way back before I'd defected to OS X, Enlightenment (0.16) was a visually amazing graphical environment - IMHO better in many ways than anything else out there, OS X included. From an end-user point of view, though, it was sometimes maddening the way they (well, probably mainly Raster) would plug along on 0.17 and these libraries, then decide to scrap everything and start pretty much from scratch on a different approach - that happened at least twice while I was a user, and I'd bet it's happened since I stopped really paying attention to the project. But it's great to see that they finally stuck to it and have brought the libraries to 1.0 - Enlightenment still has much to offer, and is still in some ways is still ahead of everything else. If I could drop it into place on my Mac and use it for everything - not just X11 apps - I'd probably still be running Enlightenment.
#DeleteChrome
Will the HURD finally be completed? Mass hysteria!
Given the relative length of time for Enlightenment updates and releases it's fair to say there are more then a handful of new coders that have come unto the market. I know, I know, we keep reproducing vermin upon vermin, but alas there is nothing I can do to stop such things.
It does entirely no harm and absolutely some good to entice new developers into your product.
The worst that could happen is you ruffle someones feathers who doesn't appear to understand the basic concepts of marketing a product. All in all, not a great loss because feathers will eventually fall into place.
"You should always go to other people's funerals; otherwise, they won't come to yours." -- Yogi Berra
Where are the Debian packages? There were supposed to be an earth-shattering Debian package!
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
Distro's set rules. But not all distros use the the same numbering scheme for versions. Then move outside a distro and role your own using source code and things can get very interesting. So, yes you are right within your distro, but many distros renumber and apply patches to the source before distribution as a package. So consistency within a distro is maintained, but as you noted there are exceptions. Stating "schema: major.minor.patch" is nice, but lacks definition. Define major, minor, and patch. "Patch" could be the distro patch or a patch from the project. Is 0 in major mean the software is alpha, beta, production? Does an even number in minor mean stable or unstable? How high are numbers allowed before you must increment your major version? Is version 3.898437658675.22 realistic? A better question is does it really convey any useful information, or cause confusion?
No, it isn't. There isn't a single actual "review" at those links, nor did I see one linked to from those pages, either. And couple of small graphics does not a set of screenshots make. I even searched via Google, and did not find either a real review or a set of screenshots showing its default installation state, or anything else of that nature, on the leading page of any of my searches.
The message I replied to was looking for API documentation.
Its all there. Follow the link to the Foundation Libraries, ( http://www.enlightenment.org/?p=news/show&l=en&news_id=28 ) and drill down for documentation.
Asking for screen shots of APIs Is kind of like asking for screen shots of a dictionary. But the GP did not ask for screen shots.
Sig Battery depleted. Reverting to safe mode.
Excuse me. With this "new" Slashdot layout, it's harder to tell what is a reply to what.
The APIs are there, but not what I was looking for.
It's a desktop library, or set of libraries. As such, I would expect it to have a default. Or at least examples of how it looks and works, given its most basic (default) settings and behavior. Every other desktop setup I have seen has had such, from the beginning.
Further, I am not inclined to try such a thing without seeing a review first.
To clarify: I wasn't asking for "screen shots of APIs". That would indeed be stupid. What I was looking for were screenshots of the results of using these APIs. Some sort of examples, at any rate.
These libraries are wrong on so many levels. It seems the E developers have not learned anything from the last 10 years of software development.
The programming language used is old and good for serious applications. Let's face the truth: C is good for kernels and device drivers, but it stinks as a general-purpose programming language. Macros, the void* type, manual memory management, C strings, init functions, OOP in C, etc are all things that hinter serious application development.
We're improving the website and documentation. There is stuff there. The problem is all those demos and screenshots and tutorials take a lot of time. take a dig through the website - about page, wiki and so on. you can look on youtube for videos of what EFL can and has done.
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
6:35PM ~ > grep typedef /usr/local/include/evas-1/Evas.h | grep Evas_Object ...
typedef struct _Evas_Object Evas_Object;
void * eh? may i ask that you actually use correct facts?
for comparisons i'm afraid I can't help you as the examples are in-house, but simply scrolling around, measuring startup time of the app and more alone has EFL pulling in general easily 2x the framerate of GTK+. GTK+ cannot overlay or blend widgets at all (not without clutter and redirection rendering). EFL can. EFL can do it with OpenGL or without. Clutter requires OpenGL, so no non-GL option. Disk size of EFL libraries combined vs GTK+GDK etc. is much smaller. You'll just have to trust me. if you don't - that's fine, but I don't make idle claims. Historically I hope that I have shown that I FIRST write the code THEN i benchmark, THEN i make claims. most software likes to make claims long before code has even been started. So if you apply those standards - you'll be disappointed. You'll just have to wait until products are out.
Maybe the fact that Samsung has tried many toolkits and has backed EFL says something? Samsung's culture is one of optimization. It must be fast. It must be smooth. They like EFL because it meets their view of the world of wanting optimal solutions. If you believe that it's all hot air, then... I guess Samsung simply hasn't done its homework or compared anything and 100's of engineers are wasting their time using EFL. I can't change your view. If you think that "maybe there is something to this" and try things out - you might be surprised. I'm sorry - I don't spend my days writing the same app in GTK+, Qt and EFL just to make you happy with perfect comparisons. Can't help you there.
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
If you're looking for an enlighment distro i heartily suggest giving the latest macpup a spin!