1. 17

  2. 8

    for your extended drama needs, head to the comments

    1. 7

      I must say I’m surprised Enlightenment was still around in 2015 (and maybe still is?) I remember it being the hot new thing in … late 1990s/early 2000s? and it basically flamed out/stalled/was passed over.

      Even at the time I got the impression it was a framework that tried to go its own way, much like a moody but intelligent teenager. Sad to see that attitude hasn’t really gone away.

      1. 8

        I remember going to a FOSDEM presentation a year or two before this article was published where the Enlightenment folks were talking about their new object model (which used a very Smalltalk-80-style pointer indirection table for object pointers, without any kind of type checking, so got all of the performance penalty of this kind of approach without getting any of the type safety. Oh, and without making any of the changes required to make this safe in a world with threads). They had invented a new IDL (because the world doesn’t have enough IDLs already) for exposing their object model to other languages, which is why I went to the talk, to see if they had something interesting that I could bridge to from high-level languages.

        Their IDL exposed C types. I asked them how I knew, from the perspective of an automatic bindings generator:

        • Whether a char* was a NULL-terminated C string or a buffer with the length in another parameter.
        • Whether a char* contained character data (so should be bridged with a string class) or a buffer (so should be bridged with a data class)
        • Whether a pointer was an input or output operand.
        • Who was responsible for freeing memory in things passed to the function.
        • What the function to free memory is (is it free or something specific to the framework) for pointers returned from functions.

        The fact that they didn’t have answers to any of these was slightly concerning. The fact that they didn’t even understand why someone would ask these questions was shocking because you need to know the answer to all of these to be able to safely use a C API even if you don’t expose them in a machine-readable format.

        After that interaction, the WTF article was no surprise at all.

    2. 7

      This is really fascinating to me, because I think the OP’s values and world view clash completely with those of the EFL authors, which causes him to present the EFL as objectively bad. It reads more like a psychology piece than an objective technical teardown (or just interpersonal “drama”, if you’re being less charitable).

      I’ve played with some of the Enlightenment libraries before and they always struck me as good design within the space that C affords. In fact, if you’re a lover of the C language, the Enlightenment libraries will probably fit you like a glove. Also, the Enlightenment-based Bodhi Linux is one of the few Linux distros that would even boot on my mother’s aging desktop a few years ago, it was so light on resources. Enlightenment has always been known for being fast as hell while still pulling off amazing visual effects with low resource usage.

      The OP of this “WTF” seems to think so highly of himself and takes down code about which he seems to have no clue, probably from wrong assumptions about how things are supposed to work according to his world view. For example, he’s ranting about the code saying “naughty programmer” and so on, but he’s passing in NULL pointers where they’re not allowed, and the code is doing well to protect against crashing and instead giving a (admittedly juvenile) hint to the coder that they made a mistake at runtime. To me, that tells the library author cared enough to check and warn the coder rather than just crashing like so many libraries do. Also, his quote about Evas_Object being a void pointer is factually incorrect (as the code’s author points out), and seems to stem from expecting C to be more like C++.

      The OP has one point though: from my memory, a few years ago (OP is from 2015) the website and documentation were absolutely and thoroughly terrible. Much of the EFL was undocumented and the website was full of dead links and abandoned pages. Also, especially in the early years there was a lot of churn with libraries being created and deprecated at a fast pace. I guess that’s the result of working on a fringe project that tries to do things The Right Way without any thought for backwards compatibility (as it started as a greenfield from scratch rewrite of Enlightenment 16 that turned into a full blown from scratch desktop environment project). In that respect, I do question his employer’s wisdom in choosing to use something so niche to build a commercial project upon. OTOH, if they’re committed, maybe they should allocate some resources to improve the upstream project while they’re at it. But it seems the developers are off working in a silo, with zero documentation and bad relations (if any) with the upstream team. A recipe for disaster, for sure, no matter the technical quality of the underlying system.

      1. 4

        Read both the rant and the author’s response. I have no problem with weird GUI APIs, that is how it is. Someone prefer it one way, someone prefer it another. Consistency helps, but not all GUI APIs are consistent with each other.

        I do have some comments on the object system based on the author’s response and the rant. There may be some historical baggage, and it is indeed difficult to do object systems within C’s constraints, but it can be done better.

        1. On accepting everything as the root class: it is typical to have void * and typedef out as the root class for object system, but nothing prevent you to only accept “FilePanel *” if that is the only thing it accepts. The upcasting to your root class is transparent, and if you ever need downcasting, it has to be explicit anyway, and having an method to do evas_as_file_panel won’t be the end of the world with all IDE assistance. C does enforce you to have a flatter object hierarchy in this case, which may be a good thing (may be not).

        2. On opaque identifier and manage own object pool: I am slowing come around to say, unless the life-cycle of these objects are the same, it is often more trouble than it worth to maintain an opaque identifier than just use pointers. Tools such as valgrind / address sanitizers interact much better with raw pointers so you don’t need to implement your own null pointer detector or used-after-free detection logic. The only place you may need opaque identifier, is probably to implement Entity-Component-System. You may be able to design a more efficient GUI API with ECS, but even in that case, a robust entity management system goes a long way (i.e., a generic auto-grown dense hashmap).

        3. On manual memory management: it is true that in C, you have to document some places need to free memory, some places you don’t, and it is a fact of life. However, a consistent API helps. In my C-API design, I normally couples every _new method with a _free method, and anything doesn’t have this suffix will have memory auto managed (maybe it is stack allocated, or the life-cycle is binded to another object, many times it is apparent why). Having such consistency makes understanding the memory management idiom within your library really easy.

        1. 4

          That’s sad to read. I used the E environment many years ago and really enjoyed it. It worked great, I guess in spite of the internals. It’s disappointing to read the developer jumping in to defend it in silly ways rather than acknowledge the issues and step back (or write a response without losing temper) - but it’s probably hard to keep calm when called out like that.

          On the other hand, I don’t do much GUI work, but I feel like this happens in every toolkit for some reason: “I called refresh() and the position didn’t change, what gives?”, “You should’ve read all the docs, refresh won’t do anything in state X when the widget is under parent Y, and actually it doesn’t refresh, but send an event to container to potentially recalculate parameters where …” i.e. things don’t always do what they say, but don’t raise an error, because that behaviour is borderline valid in some edge case. Docs may mention that, but the assumption is that you understand everything about the framework. My worst experience here would be between Gtk and Java Swing. The best surprisingly in .net WPF, but it still has some “I set this property and nothing changed” issues.

          1. 3

            This is a classic of inane API design, especially later in the thread where the author of the code responds without tact. You can immediately tell why Samsung’s custom platform attempts have been abortive.

            I assume you were reminded of it during another recent Linux desktop controversy?

            1. 2

              A friend of mine had a home automation startup called Calaos, and was using EFL back in the early 2000. I saw a video of his product and it was very impressive: buttery smooth animations, gradients, transparency. It was really ahead of the rest, and more importantly working well on an embedded device. I always thought that EFL had a lot of potential, but somehow failed to reach popularity… Maybe others felt like the author of that post?

              1. 6

                You’re completely right: EFL was jaw-droppingly amazing at the time the project got some initial traction.

                I was looking to make EFL bindings for CHICKEN many years ago, but the docs were so sparse and the library churn was so high (and no stable releases for many years that made it into distros, either!) that I abandoned the entire idea.

                There wasn’t a release for some years after they got started, until they released the “asparagus” development snapshot when they felt the project was getting ready for public use. But then, for many years, development continued while the only “release” that was available was that very development snapshot.

                Edit: heh, regarding the churn - it looks like they kept rewriting Enlightenment (the WM at least?) over and over (all the while making it slower and slower), so much that the Bodhi Linux guys felt the need to fork it for their distro to keep it stable and fast.