[daurnimator]

> Not to mention the sad state of UI toolkits right now. This isn't about GTK vs. Qt or anything... but you can't pick up your favourite language (Python, JS, whatever) and easily write cross-platform apps that work well on Linux.

This frustrates me to no end.

- Qt is almost impossible to fully bind. The vague hacks we had all got tossed out the windows with the move from Qt4 to Qt5. I've given up putting my own effort in here.

- GTK had some good progress with gobject introspection, but it's like talking to a brick wall trying to get issues fixed. Not to mention that it doesn't work as well as other toolkits on other platforms, and I dislike their new "look".

- wxWidgets is very hard to bind well.

- Motif never "feels" right

- IUP is sort of a dark horse, but I've never managed to build a nicely working application in it, and the build process is a nightmare (though it has improved).

Not to mention that each toolkit ends up trying to push their own weird languages and ui designer IDEs.

At the moment I'm crossing my fingers that libui https://github.com/andlabs/libui/ won't mess up. But for now it's quite incomplete.

[rasterman]

We may have come up with an alternative for bindings - at least for EFL, where we now generate the C API from an IDL that expresses classes, inheritance, events (signals/slots), etc. so our C API is pushed out by code gen tools and we just fill in the functions, and right now we support automatically generating C++, JS and LuaJIT bindings out of the box whenever you type "make" on the toolkit. We're going for "full bindings with zero maintenance overhead EXCEPT for fixing bugs in the generators or the initial work for adding a new language binding tool". At least the plan is to have language bindings "first class citizens" all coming out of core development (with yes, the core still in C - that's how we roll). Our cross-platform support hasn't been great and originally it was never intended/planned, but now we do port to Windows, Mac and Linux (X11 + Wayland), other Unixen... sure the ports need more work/maintenance and to be made easier and less prone to breaking, and we don't have iOS, android or Windows Phone ports (and no obscure OS's like Symbian, QNX etc.), so that's something to fix, but we're shifting design to push portability first and foremost and that allows for OS ports, so maybe this will pan out. There are Python bindings waiting int he wings that will come in once we're done with our interfaces work and the core OO layer is stable (not changing/breaking), so that language will get added. given the range of languages above and Python I think that means that adding more languages shouldn't be hard as most core concepts have been covered. Just FYI on "pick up favorite language and write cross-platform app".

[daurnimator]

> LuaJIT bindings

Well... somewhat. FWIW I was present at q66's talk at the lua workshop last year (https://www.youtube.com/watch?v=J_hlbjj_9-Q). From what I recall it was more of a full application framework rather than a library usable from existing processes.

I did try to give them a go at some point, but could never get things working.

Aside from this, the reliance on luajit makes this a no-go for me. (though perhaps you can use luaffi (https://github.com/facebook/luaffifb) to alleviate this?)

[rasterman]

well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

But yeah - we bound to LuaJIT because of performance and FFI. Technically bindings could generate C code for PUC Lua too. We generate C++ for v8 for JS, so it's possible but not done. My point was that we're making bindings a first class citizen part of development of the core. maybe this will fill in the gaps others have tried to fill before?

[daurnimator]

> well it's a framework like Qt is... :) or like GTK+ and glib and then some. so if these were acceptable for bindings if they were maintained/up to date then EFL would be.

Languages want a something that can act as a library; not something that completely dictates the structure of your program. e.g. you must be able to specify your own main loop.

Glib does allow this, however the gobject introspection for it is completely broken. I haven't looked into it for Qt for a while

[rasterman]

node.js insists on its own mainloop. python is agnostic. efl already integrates with node's libuv usage and glib mainloop. really gtk requires a glib mainloop. you make glib integrate/sit on top of something elses and efl did the same thing.

[daurnimator]

You're saying you don't make efl run on top of your own mainloop, but instead integrate with ecore? Isn't ecore part of efl anyway?

Either way, is the mainloop-integration part exposed in the bindings? `grep -r main_loop_iter /usr/share/elua` doesn't show me any results.

I just installed 'efl' (on archlinux), and I get a binary "elua" (which is a conflicting name with the famous project http://www.eluaproject.net/) which wants to be my executable. How can I just use my already installed luajit? Why would you even encourage a executable for this?

[ufo]

> Qt is almost impossible to fully bind.

You know a system is hard to write bindings for when noone is able to create Lua bindings for it.

[mushiake]

smoke/kde was supposed to be contender for gobject-introspection, however it is barely maintained.

It is only(?) used by common lisp[0].

And there was claro[1].

[0]https://github.com/Shinmera/qtools

[1]https://github.com/Araq/Claro

[daurnimator]

It too seems to be stuck on Qt4.

Only python bindings seem to have made it up to Qt5.