Enlightenment EFL 1.20 Released

[jKicker]

Kudos for the work really. Especially for the comparison of the Qt state which shows what can be seen from the issues list and my personal experience. A lot of bugs in Qt. I'm very happy to see your work on stabilizing EFL!

[cl333r]

I'd switch to EFL if it was written in C++ (I've had enough of C++ bindings with Gtk), mostly because of the horrible mvc implementation in Qt5 (I hate QModelIndex and all the other classes).

[microcode]

Frankly I wonder why GNOME hasn't ditched GTK in favour of EFL over the years. ;- )

[raster]

I'd switch to EFL if it was written in C++ (I've had enough of C++ bindings with Gtk), mostly because of the horrible mvc implementation in Qt5 (I hate QModelIndex and all the other classes).

Well... we're not going to write in C++, but we have another way of doing this. Unlike gtkmm - we don't have separate manually maintained bindings. We have this new IDL thing we made specifically for EFL and our object model/system. we write out classes, methods, etc. in an IDL language that is then used to code generate the C interfaces ... and then also code-generates the C++, JS and Lua bindings too. It means that everything we have in our object model so far comes out 1:1 in C++. it looks, smells and feels like C++13. It follows STL style. The bindings are actually header-only template beasties so the ABI you depend on is not C++ but C. You can override methods from the C and so all your usual stuff. It's built around RAII as it's philosophy. I know it's not what you want, but I suspect it's better that the way gtkmm does things.

We have the same experience with manually maintained bindings. They are forever behind, always a subset and have to keep up (python bindings). We really wanted to solve the issue of supporting many languages with as little effort as possible and this is what we've come up with. Also ... the bindings are re-generated every time we compile EFL. So they aren't a separate project with a separate release... they are kept in sync explicitly by making them a core feature.

We're still working on doing a nice API for it that's sitting on top of the same core code. We've done our first stage where we slid this directly under our old C API and made it just "work". Now we're redesigning around this to have a very clean and tidy multi-language API. Maybe it'd work for you.

But keep in mind we really want to support lots of languages in the end, so we have to pick solutions that make that as easy as possible with the best possible results.

[raster]

Frankly I wonder why GNOME hasn't ditched GTK in favour of EFL over the years. ;- )

Well EFL didn't exist then. EFL was spawned out of Enlightenment development like GTK+ came out of GIMP. GTK+ long preceded EFL, so GNOME had already made their choice of toolkit before then. GNOME did use Enlightenment as the WM but there were fundamental philosophy differences. I dislike breaking a desktop up into lots of little processes (panel process, filemanager process taking over background, pager process, start menu process, battery meter process, taskbar process ... etc. etc.), but GNOME people loved it. Look at the number of processes running in a simple bare GNOME desktop login. Well at least for GNOME 2.x ... Enlightenment has a very small set of processes running. I believe in fewer process for efficiency and integration reasons. Enlightenment makes it modular (and has done so for over a decade) but using loadable plugins/modules which are just blobs of code to run inside the WM. Interestingly GNOME now is similar with GNOME shell being more of a big process and it being extended by bits of code in JS run under a JS VM inside the WM/compositor process.

Enlightenment had a pager of it's own. It's own main menu system, it's own almost everything GNOME wanted to replace with an external app... all of this had to be turned off so GNOME could be happy and have a WM that was just a "Dumb WM slave that did what GNOME told it to". For a long time in the early GNOME dev days I said "you need a WM to build GNOME. trust me. You can't do this "GNOME will run under any WM" thing". Miguel disagreed repeatedly. I was willing to tailor development to GNOME's needs. GNOME said they didn't need a WM. After maybe 6-12 months of this I gave up and just made E do what I wanted whilst also working on other GTK+/GNOME things and then it was "OMG! we need a WM!" ... ok - so I added the features GNOME needed and adapted enlightenment, but I wasn't going to tear down the features I had built. We disagreed. Interestingly GNOME today is so heavily reliant on it's WM (GNOME shell) that is looks a hell of a lot like Enlightenment's design... but the subtle differences are there.

I also disliked the desire to copy everything windows did almost to the letter. I thought it robbed Linux and it's GUI of it's identity. If you copy you will always be a poor "it's not the same" copy. Celebrate your difference. It's one of the best marketing tools you have. That was how things were back in the late 90's with GNOME.

So they couldn't have used EFL ... it didn't exist. EFL started later but also with a very different rendering philosophy. We started as a 2D scene graph and then built widgets on top of that. Interestingly that GTK+ is slowly more and more moving to this direction too. Our abstracted scene graph means we've been able to use OpenGL (OpengGL-ES/EGL too) as well as software rendering for many many many years (well over a decade) for a 2D UI. but GNOME had already made their decisions long before that. FYI the inspiration for doing the scene graph came from Frederico Mena's (GNOME dev) GNOME canvas. It really was under-used and under-appreciated. I thought it was a fantastic idea.

[ermo]

@raster:

Is your cat (Malloc?) a Maine Coon?

Congrats on the EFL release. Feels like Enlightenment has been around more or less forever now...

[raster]

Yes. They use the software that happen to work. Wise choice. EFL is just like kde.

Actually EFL is like GTK+ or Qt ... not KDE. Enlightenment would be like KDE. But hey - details. Who needs to know them.

[raster]

@raster:

Is your cat (Malloc?) a Maine Coon?

Hmmm... No. Malloc is not a Maine Coon. Just an unusually big domestic medium hair tabby. But we suspect he has some Siberian in him as he behaves very much like one and "hurrrrs" also like Main Coons do as well oddly enough.

Congrats on the EFL release. Feels like Enlightenment has been around more or less forever now...

It feels like it too!

[monraaf]

Hey raster,

nice new site! But I miss the "files" directory you kept for the last few versions, there were always interesting things in there for the last ~15 years? :-)
Where do you place your temporary data now?

Regards

[raster]

Hey raster,

nice new site! But I miss the "files" directory you kept for the last few versions, there were always interesting things in there for the last ~15 years? :-)
Where do you place your temporary data now?

Regards

hmmm. i don't put it anywhere atm. i guess i'd have to ensconce it in a post... even then my new web engine can't do arbitrary data files yet.