Improved Wayland Application Redraws Coming To Enlightenment's EFL

[phoronix]

Phoronix: Improved Wayland Application Redraws Coming To Enlightenment's EFL

Samsung's Open-Source Group has been working on making their Wayland support in the Enlightenment Foundation Libraries (EFL) even better...

http://www.phoronix.com/scan.php?page=news_item&px=EFL-Wayland-Redraws

[cl333r]

Awesome. Maybe someday EFL will take over Gtk/Qt.

[ssokolow]

Awesome. Maybe someday EFL will take over Gtk/Qt.

Not likely any time soon (TL;DR: The EFL APIs are a horror to work with if you're not the EFL guys.)

[Cape]

EFL is truly great on the technical side. Unfortunately, the licensing and the API (due to lack of personnel I think) are killing it..

[ozric]

Not likely any time soon (TL;DR: The EFL APIs are a horror to work with if you're not the EFL guys.)

LMAO - the 3yr old rant from a 'developer' that can't read docs? Too funny. We don't hire 'developers' like that guy, they are useless. Never had a problem using EFL, but then again I can read documentation and apply what I've learned lol.

[hansg]

LMAO - the 3yr old rant from a 'developer' that can't read docs? Too funny. We don't hire 'developers' like that guy, they are useless. Never had a problem using EFL, but then again I can read documentation and apply what I've learned lol.

Rather than attack the messenger, perhaps you could answer a simple question: is he right? Are there void pointers everywhere?

[raster]

Rather than attack the messenger, perhaps you could answer a simple question: is he right? Are there void pointers everywhere?

If you read rebuttals instead of just original posts and actually look for yourself at the purported library APIs... it's not full of void pointers. Of course callbacks get passed void pointers as "generic data" the same as Glib/GTK+ (as an example as these also have are C based). This is the way to pass an "unknown piece of data" around in C generically. The API is typed for objects and everything where types can be usefully applied. He's right that the original person couldn't read documentation. Not even the most basic hello world examples. like

https://www.enlightenment.org/develop/efl/start

https://www.enlightenment.org/develop/legacy/tutorial/basic_tutorial

And then a smattering of API's obviously not full of void *'s for everything:

https://www.enlightenment.org/_legacy_embed/elementary_main.html

https://www.enlightenment.org/_legacy_embed/ecore_main.html

https://www.enlightenment.org/_legacy_embed/eina_main.html

https://www.enlightenment.org/_legacy_embed/group__Eina__Inline__List__Group.html

https://www.enlightenment.org/_legacy_embed/group__Eina__Hash__Group.html

https://www.enlightenment.org/_legacy_embed/group__Eina__List__Group.html

Below ignore EOAPI calls as these are disabled behind a #ifdef in headers and doxygen picks them up anyway. Those API's are auto-generated from currently in-flux IDL files and marked as unstable, but they just turn up in the auto-generation unfortunately for now. It'll get cleaned up once that in-flux work has settled:

https://www.enlightenment.org/_legacy_embed/group__Elm__Table.html

https://www.enlightenment.org/_legacy_embed/group__Elm__Button.html

Yes there are void pointers. Where they are needed (adding some generic thing to a list, or a hash table, or to generic event callbacks). But it's not "full of void pointers" as described. Not beyond what C would really require. Most of the post is full of hot air except some forgotten debug printfs. It's someone with a chip on their shoulder probably, but do the research for yourself. The API's are not perfect. There's history with many having been developer separately and then brought together over many years. Originally an application internal API that was exposed as "maybe this'll be useful to others" and morphing over time. The docs could be far better, but that's exactly the kind of thing someone with money should invest in if they want high quality docs, but if you spend a little time reading some docs, some samples and then poke around a bit and ask some questions... it's fast enough to figure out and get stuff done. There's lots of value in asking community as lots of knowledge is there. Don't do any of these and I'm sure life will be harder.

[c117152]

Rather than attack the messenger, perhaps you could answer a simple question: is he right? Are there void pointers everywhere?

C++ lets you abstract some of it away so casting QObjects means less void pointers. But, this is only a relevant when comparing GLib's GObjects, Qt's QObjects and the EFL's Eo's / Evas' objects in the space of C/C++. In the wider world of GUI OO languages, EFL+C, GTK+C and Qt+C++ all rank pretty poorly with the EFL having some distinct advantages in embedded over the rest much like how Qt and GTK have their own advantages in other spaces.

In the end, I think most devs will pick up Qt since it's better documented and easier for small desktop projects. But if you need to stick a commercial grade GUI on an embedded SoC, then Qt is too slow and GTK is too ugly.

[raster]

C++ lets you abstract some of it away so casting ...

Yes. C++ does. GTK+/Glib and EFL have a C API though, so void pointers appear more often for "generic handles to something". It's just a fact of life. You could come up with verbose mechanisms at some point to have a type but then sooner or later the input would be void pointers.

This is why we've been working on EO - it's an IDL system to define an interface at a high level and it code-generates the C API, as well as a fully typed "typesafe" C++ (c++ 13) API, and also is doing Lua (LuaJIT+FFI), JS (node/v8) and now some C#/Mono bindings too. The bindings are auto-maintained per language via generation every time you "run make". You can also take any class an inherit it in any of the binding languages and override methods and so on and it works. the C++ API is all templates/headers only so the ABI is C, thus side-stepping any lingering C++ ABI issues you'd have in some cases.

You (generic you) can choose to be a language "bigot" and think one language to rule them all, or try something else like the above. Try and support many languages as nicely as possible and ALSO don't leave C out of it either. It's rather ambitious and we'll see how it goes, but at a technical level at least it all works and it does produce a consistent API across multiple languages with zero maintenance effort unlike manual bindings. GObject chose a different path with introspection. I kind of think that compile-time generation is probably going to be better in the end.

[discordian]

Rather than attack the messenger, perhaps you could answer a simple question: is he right? Are there void pointers everywhere?

void pointers can make sense, if you care for binary stability, ideally you would never have to cast them manually however. The rant above just shows how clueless this guy is about everything.
C/C++ do not define or care about boundaries outside of source-code files, if you want a stable ABI you can't use C++. ELF is built around C-Style symbol names and everything you add on top of that, you either wont be able to use system-wide (on Windows and Linux anyway) or have to compile from source with the same compiler and settings to guarantee the symbols are named identically.

You can add wrappers adding type-safety on top, so this is not an issue anyway. Or even use bindings for Rust, which suddenly makes unicorns appear and all bugs go away.