6 ms·

> 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, w

> 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/ https://github.com/andlabs/libui/ won't mess up. But for now it's quite incomplete.

mushiake 10y ago
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 https://github.com/Shinmera/qtools [1]https://github.com/Araq/Claro https://github.com/Araq/Claro
- daurnimator 10y ago
  It too seems to be stuck on Qt4. Only python bindings seem to have made it up to Qt5.
ufo 10y ago
> 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.
rasterman 10y ago
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 10y ago
  > 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 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 https://github.com/facebook/luaffifb) to alleviate this?)
  - rasterman 10y ago
    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?

mushiake 10y ago

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 https://github.com/Shinmera/qtools [1]https://github.com/Araq/Claro https://github.com/Araq/Claro

daurnimator 10y ago
It too seems to be stuck on Qt4. Only python bindings seem to have made it up to Qt5.

ufo 10y ago

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

rasterman 10y ago

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 10y ago
> 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 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 https://github.com/facebook/luaffifb) to alleviate this?)
- rasterman 10y ago
  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?