Forgot your password?
typodupeerror
Enlightenment GUI Graphics Programming Upgrades

EFL 1.0 Is Finally Released 115

Posted by timothy
from the just-when-you-least-expect-it dept.
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.
This discussion has been archived. No new comments can be posted.

EFL 1.0 Is Finally Released

Comments Filter:
  • by sznupi (719324) on Saturday January 29, 2011 @02:15PM (#35043610) Homepage
    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...
    • by malloc (30902) on Saturday January 29, 2011 @03:59PM (#35044206)

      Some time ago there were hints & speculations that Samsung bada mobile OS might use some Enlightenment libraries.

      Considering that Samsung hired [rasterman.com] Carsten Haitzler, the main figure behind E17, that wouldn't be too far fetched.

      • by raster (13531)

        I'm still here (@ Samsung). What comes out and when is not something I can say, but Enlightenment and EFL are in heavy use here at Samsung R&D. Samsung Mobile platform R&D isn't a small place either. EFL actually does what very little else can do and generally faster or much faster, with more flexibility and smaller footprint. And it improves day by day. Expect a stream of releases and new libraries, and so on over time. Priority is in getting things right for long-term longevity, not short-term pub

  • I would like to see a thorough review of EFL, with good descriptions and screenshots, before I download and install them on anything.
    • by Anonymous Coward

      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 installin

      • by Cylix (55374) * on Saturday January 29, 2011 @02:47PM (#35043788) Homepage Journal

        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.

      • how about the API documentation and some sample code?
        • by icebike (68054)

          Follow the links in the article. Its all there.

          • 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.
            • by icebike (68054)

              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 [enlightenment.org] ) 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.

              • 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.
    • by Anonymous Coward

      Well, you could go to PC Linux OS [pclinuxos.com] and download the e17 iso. Load it up on a VM and test it out.

      • by X0563511 (793323)

        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.

  • by Saija (1114681) on Saturday January 29, 2011 @02:16PM (#35043620) Journal
    As a linux enthusiast, user and eye-candy lover what could i do with this? honest question, is this the core to build enlightment?
    • Re: (Score:3, Informative)

      by Anonymous Coward

      Enlightenment is a window manager. The EFL are the libraries that the E team wrote in order to write E17 (Enlightenment 0.17), which was a complete rewrite from E16. If you are a developer you can use the libraries to write your own programs. The summary contains an overview of what does what (Except that it is Edje, not edie). If you are just an end user, then it is just libraries that are in E17's core, and thus it depends on them. For you the release would mean that E17 has less problems than before, and

    • Re: (Score:2, Informative)

      by Anonymous Coward

      It's the basis of e17, yes. And e17 is a wicked-slick desktop environment; works quite well on netbooks, tablets, etc. Fully DPI-independent, tons of eye-candy, and it's still snappy on a dual-core 800MHz Turion (my old HP TX2000, locked on the lowest clock speed for maximum battery life, was where I first met it.)

      However, it's a general-purpose set of libraries usable for any app. For example, on my N900 (running more-or-less stock Maemo, with not a trace of Enlightenment involved) I use BlueMaemo (a bluet

    • by Saija (1114681)
      The 2 Ac's response just cleared me the topic of this thread, +1 informative for you guys.
  • by Xtifr (1323) on Saturday January 29, 2011 @02:17PM (#35043636) Homepage

    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!

    • by Ant P. (974313)

      So is the E17 desktop "officially" released now, or what?

    • 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 tha
      • 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.

      • by Xtifr (1323)

        And everyone does these version numbers differently.

        Do they? "Everyone?" Really? I have thousands of packages available for my distro that all use more-or-less the same schema: major.minor.patch. I have to hunt long and hard to find exceptions. The fact that it's nearly mandatory for libraries to use this schema in order for so-versioning to work no doubt helps.

        We should all find a standard we can agree on mostly

        We've got that. Yes, "mostly" is an important word there, but it's enough that I think it can meaningfully be described as a de-facto standard. The GNU version of ls(1) even has a "-v" flag to

        • 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.
        • by raster (13531)

          i think he was implying that version 1.0 MEANS something different to different development teams. same with 2.0, 3.0 etc. etc. - where one group will rapidly move up from 1.0 to 2.0 then 3.0, 4.0 and jump to 7.0 or whatever another will lurk in 0.1, 0.2, 0.3 and maybe take many years to hit 1.0. it mostly centers around "what meaning do you attach to 1.0, 2.0 etc." is 1.0 just "its ok and seems to work" vs "this is golden and well polished. very solid and you have mountain of features and are very unlikel

      • Six-monthly adjectives?

        e.g. start at 'warty', continue with 'nutty'.

    • by Lisandro (799651)

      In fact, this would be the first stable release of the EFL libraries. I've been following the development of Enna [geexbox.org], and the main branch would regularly break due to changes on the EFL API.

      • by raster (13531)

        That shall no longer happen with 1.x EFL libs. :) thought elementary that it relies on is still not 1.0 yet... just wait. :)

    • by bonch (38532)

      Talk about being pedantic as hell. Obviously, the phrase "first version" is in reference to the idea of the first public, stable version as denoted by the version number 1.0.

  • It may be enlightened, but can it immanentize the eschaton?
  • by iluvcapra (782887) on Saturday January 29, 2011 @02:27PM (#35043676)
    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.
    • by Anonymous Coward

      There are 5 or 6 different frameworks on every platform, and hundreds of people rolling their own (less common on Linux and mac). Not unusual at all.

      • by iluvcapra (782887)
        Really? I mean, on a Mac you use Cocoa, all vendors use Cocoa -- they don't have to, some people rope STL into the fray, but that's because of language issues with legacy code. Why would you write a new one of these libraries, when half a dozen people have already written the same add-functions-to-C-to-bring-it-up-to-parity-with-Python libraries?
        • by Xtifr (1323)

          I mean, on a Mac you use Cocoa

          Well, except for the people who use, e.g., E17 and/or the EFL on Mac. This is a cross-platform library and desktop, not something specific to Linux, so the original question ("why does Linux have...") makes no sense.

          Ignoring that huge quibble, though, the answer is: because Linux is not trying to be a one-size-fits-all solution, but rather an available-in-many-sizes-to-fit-your-needs solution, which is something that a lot of us greatly prefer.

          • by smash (1351)

            "people" do that on the mac, or just a single person? seriously, the whole point of the mac is to get apps that fit in with the rest of the system, and they are cocoa. given how much stuff cocoa can do for you, it boggles the mind as to why you'd bother NOT using it on the mac, unless you're doing some shitty half arsed port of something and in that case very few mac users are going to go for it because compared to the rest of the apps on the system it will likely look and run like shit.

            just sayin....

            • by tibman (623933)

              You are silly. If someone makes a cross-platform game or program.. they will have to use cross-platform libs.

              • by smash (1351)

                No, they don't HAVE to.

                If they want to do a shitty port, they do. If they want to make it cross platform and actually decent, you separate the UI code and use #defines for native toolkit for platform.

                • by tibman (623933)

                  We're not talking about just UI. But ignoring that, if someone wants to maintain several different front-ends.. they certainly can. Not everyone wants to though.

                  I think you are misunderstanding what a port means though. Typically they are a conversion from one system to another because the same code doesn't work on both. Cross-platform specifically means it works on both platforms with identical code. I do understand what you are saying though. That if you want the mac version of your program/game to

            • by spauldo (118058)

              I dunno, I wanted to buy a mac back in the day so that I would have the best of both worlds - availability of various bits of commercial software unavailable on Unix and the ability to run Unix apps without dealing with hacks like cygwin (don't get my wrong, I like cygwin, and I have nothing but respect for its developers, but it's a hack) or wine (same disclaimer). You can run quite a bit of Unix software on OS X, and most of the commercial software programs I wanted are also available.

              I decided not to af

              • by smash (1351)
                If thats the case, install ubuntu. Using a mac to run non-cocoa apps is kinda killing a lot of the real point of using the mac.
                • by spauldo (118058)

                  What's the real point of using a mac? Mostly what I've seen, the *point* of using a mac is to take your pretty little 4oz laptop into a coffeehouse and act like you're better than everyone else.

                  I mean, seriously, if all I wanted to do with computers was what some company thinks I should do, I would run Windows. I certainly don't use my iphone the way Steve Jobs thinks I should (i.e. I don't buy anything in the app store or from itunes and have the thing jailbroken to hell and back). I don't use my laptop

          • While it is technically possible to use Enlightenment on the Mac or even on Windows, nobody actually does this except as a larf, so this "huge quibble" can indeed be safely ignored.

    • by Hatta (162192) on Saturday January 29, 2011 @03:17PM (#35043960) Journal

      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?

      Because 5 or 6 different groups of people thought it would be fun to write their own desktop frameworks.

    • by Svartalf (2997)

      Because they've been around, developing this since before KDE and GNOME were little more than an idea on someone's drawing board (not to mention some of the initial bits and bobs for GNOME came from Enlightenment.

      • by CRCulver (715279)
        E17 and EFL are complete rewrites and date from long after the writing of GNOME. There is no code left from the versions of Enlightenment that predate GNOME.
        • by spauldo (118058)

          There may be no code left from that era, but the ideas and community have remained. The Enlightenment community and the GNOME community have very different ideas on a lot of things.

          That being said, I haven't use E since DR14, which I couldn't stand (DR13 was twelve kinds of awesome, though). A lot of the ideas we think of as standard first gained headway in E - imlib and esd were both originally part of Enlightenment, and eterm was the first popular terminal to support background images and pseudotranspar

    • Because container classes, marshaling, runloop, event handling, and string libraries are all small compared to the rest of the framework.
    • by raster (13531)

      You can just have a ford model-t like everyone else. as long as you like black. if you don't... too bad. :)

      Seriously, it's choice. it's competition. If you didn't have choice or competition everything would stagnate. You are free to say that EFL, or GTK+ or Qt or whatever just isn't your choice. It may not provide more than what you currently use, but other people may find it a benefit. There is a big cost in working with an existing framework. You have to carry its history along with you and baggage. When

  • by CAIMLAS (41445) on Saturday January 29, 2011 @02:27PM (#35043680) Homepage

    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.

    • The real question is: Did they slim it down, or did everything else exceed E17's bloat?
      • by icebike (68054)

        An, given their history, is there any reason to expect better support and continuity tomorrow than has been apparent for the last 10 years?

        I've been in and out of Enlightenment several times over the years an I always end up scrapping it for something else due to the chaos. Its fine if you install it and leave it alone, then nuke it and install it again upon the next release. But migrating from release to release has been frustrating.

        Now that we have exhausted all the K words and the X words, it will be i

      • by CAIMLAS (41445)

        In retrospect I think it's a combination of both slimming/improvement as well as other things bloating faster. The design for the libraries didn't change much since inception, just the implementation. "We can do this better" was their mantra. Compare that to GTK, KDE, or even Windows and OSX, where the libraries have almost invariably increased in bloat - the old stuff wasn't improved upon, it was augmented by new stuff or replaced outright with heavier functionality.

        E17 ran acceptably with 128Mb of RAM bac

    • by Xtifr (1323) on Saturday January 29, 2011 @03:02PM (#35043888) Homepage

      It may have taken 10 years to 'get right' (or close to it) but the end result is, frankly, quite impressive.

      Did it take 10 years to "get it right", or did it merely take 10 years for the competition to blast by in terms of bloat and overhead, making E17 look better simply because it hasn't gotten worse anywhere nearly as quickly? :)

      This is an honest question, as I haven't followed E development at all. I do basically agree with the conclusion--E17 once seemed huge, bloated and slow, and now it seems small, effective and fast. Clearly the devs were doing something right along the way, even if it was simply not adding new kitchen sinks every year or two.

      • by Svartalf (2997)

        I think it's a bit of both, in truth. They've refined things as best as I can tell, so there's at least slightly less apparent overhead than before- and the others blew past them ages ago and didn't stop adding stuff. Some things we needed...many we didn't.

      • by cp.tar (871488)

        The way I remember it... no, it wasn’t like that.
        E16 was a feature-rich, but pretty bloated window manager. E17, when I first tried it some seven years ago, was very lean: I’d put it on a computer too underpowered for either Windows XP or the then-current version of either KDE or Gnome. All of them positively dragged.
        E17 was not very stable, but it was small and fast, and its image viewer (AFAICT also discontinued) ran circles around GQview. Zooming huge photos in or out was instantaneous in E

        • by CAIMLAS (41445)

          E16 was a feature-rich, but pretty bloated window manager. E17, when I first tried it some seven years ago, was very lean: I’d put it on a computer too underpowered for either Windows XP or the then-current version of either KDE or Gnome. All of them positively dragged.
          E17 was not very stable, but it was small and fast, and its image viewer (AFAICT also discontinued) ran circles around GQview. Zooming huge photos in or out was instantaneous in E; GQview would take up to 10 seconds.

          I ran E16 on my 233Mhz with 128Mb of RAM without much issue; the early builds (about 10 years ago) were a wee bit bloated when I stopped trying them; it was faster, but more bloated. As of 7 years ago, I think efm was long discontinued - and it was just getting started in the timeframe I was thinking of (if that's any help). I stopped using Enlightenment by the time XP came out, but I can't imagine it was all that slow. (Though, E16 is relatively slow on newer hardware, too - it's just not that well designe

      • I also haven't followed E development, but if 1.0 means "feature complete", then perhaps they simply reached their target? Or maybe they simply hit a baseline flexible enough that they can tack on whatever they like afterward, akin to how future "versions" of OpenGL use extension/capabilities listings.

    • by raster (13531)

      I have to thank you for the comment. Mostly because it is actually thoughtful and realistic. You actually followed history and development and though many people - even you, lost patience, you've come to see that the stubbornness of EFL development actually has paid off. It's achieved what it was meant to. :) Now we get to improve it even more while people can build things on top of a stable API.

      • by CAIMLAS (41445)

        Raster - oh, I followed it right along; I just never really understood the push until I saw E running on smart phones in the last couple of years.

        I appreciate the dedication, even though I will not likely directly appreciate the result (ie build something using them - I'm not much of a programmer). Someone with less vision would've probably bogged themselves down with a public wm release, and burdened by support and bugs, would've never gotten their libraries to where they idealistically wanted them.

        While I

      • by riondluz (726831)

        Hi:
        Just wanted to say thanks for a great UI/WM/DM
        I've been using E since day 1 (literally) and continue to enjoy it. I've built from source, tho
        compiling EFL and makeing edj files still somewhat eludes me. And I usually find myself still running gnome panels on the side.
        But E17 has proved stable and indispensible on my workstations. I use trans-set at times and would like to see more window transparancy tools, but that's my only lament do date.
        Thanks for a great contribution to OSS bud. I can't wait to se

  • Quick question: (Score:5, Insightful)

    by lennier1 (264730) on Saturday January 29, 2011 @02:48PM (#35043792)

    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?

    • Because as far as I can tell, E17 isn't actually out yet. This article is about a set of libraries E17 will depend on, none of which contain widgets or other graphical components.
      • by X0563511 (793323)

        Huh, that's odd:

        Available Packages
        Name : enlightenment
        Arch : x86_64
        Version : 0.16.999.050
        Release : 6.fc13
        Size : 5.9 M
        Repo : fedora
        Summary : Highly optimized and extensible desktop shell
        URL : http://enlightenment.org/p.php?p=about/e17&l=en [enlightenment.org]
        License : MIT
        Description : Enlightenment 0.17 is desktop shell based on Enlightenment
        : Foundation Libraries. It's highly optimized and provides extensive
        : theming capabilities. A Desktop shell means it's a window manager
        : plus a file manager, plus configuration utilitys all in one. It
        : works reasonably fast even on old and low range computers,
        : providing eye-candy environment.

    • by Svartalf (2997)

      Heh... Define "full size". If you're talking about the bunch that typically do Enlightenment as their main desktop environment, you're going to find 1920x1280 as a common resolution. Something that big's going to be hard to do "full size" not to mention the bandwidth overheads of this.

      • by omni123 (1622083)

        Uh?

        I think he is referring to some easy to find links to screenshots which is obviously of little concern no matter the resolution of those using it. The definition of "full size" he is referring to is more like "doesn't feel like I forgot my telescope in my other pants".

        There are a couple here [enlightenment.org] but they look nothing like the marketing material on the main page (and are almost 2 years old).

  • 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

  • by Tumbleweed (3706) * on Saturday January 29, 2011 @05:06PM (#35044526)

    Will the HURD finally be completed? Mass hysteria!

  • Where are the Debian packages? There were supposed to be an earth-shattering Debian package!
    • by blackpig (1112913)
      I see what you did there Marvin... err, Martin.
    • by deek (22697)

      They're in sid (unstable). I'm running the Debian e17 packages. I've pinned my system to testing by default, and selectively installed unstable packages as required. E17 works great. It's easily my window manager of choice.

  • Well okay (Score:4, Interesting)

    by MichaelSmith (789609) on Saturday January 29, 2011 @05:38PM (#35044694) Homepage Journal

    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.

  • 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.

    • Maybe the folks writing the software have gotten over their newbie gripes about the language.

    • by rackeer (1607869)

      I agree that C should not be the way to go for application programming. Developers should value their own time more than they value the computer's time, even more so that computers get so fast and interpreter implementations so good that the difference is hardly noticeable. When I am looking for applications to use and have the choice of one programmed in C/C++/C#/Java and one programmed in python, I'll choose python, because I assume that the code quality is better.

    • by dvlhrns (1681218)
      LMAO...Yea, let's make a window manager in python (because that's seems to be all people know these days) ... good luck with that.
      • Actually the window manager itself might make sense written in python, so long as you use good lower level libraries like EFL. Which incidentally have good pythonic bindings for a lot of stuff, and you can use the c API for the rest. The closest to this may be the Paroli UI form OpenMoko offering a feature-phone style UI and applications via Python and EFL (admittedly the project seems to be dead now)
  • by erdraug (962369)
    If you're looking for an enlighment distro i heartily suggest giving the latest macpup a spin!

"How do I love thee? My accumulator overflows."

Working...