One of the things "missing" from Go is the ability to do a GUI. Some work is being done to build out a QT library, but it seems like the progress on atom-shell and node-webkit may almost make Qt overly cumbersome to work with.
Other than native controls and the potential DOM lag of a webkit interface, is there any particular reason why someone programming in Go, Python, Ruby, etc. would want to engage Qt; assuming a stable, working library?
You say "other than", but native controls are a big deal. As an OS X user, I for one would strongly avoid using an application that uses (often generally poor, almost always slightly off with keyboard shortcuts and such) HTML replacements for native UI. (For the record, I don't use Atom, but in that case the horrid performance is more important.)
Actually, Qt suffers from this as well compared to native Cocoa, because of both small issues with reimplemented controls (as of recently, anyway) and, more importantly, generally Windows-focused UI paradigms. But it's not as bad as HTML.
When I hear "GUI" and "native", wxWidgets immediately pops up in my head, which is a decent framework and wraps native controls. I wish it had more publicity.
After trying to maintain a wxWidgets project about a year ago, I'm afraid I must disagree. It wraps native controls, but it is a horrible broken framework. Among other things,
- It uses macros instead of C++ templates in order to support ancient compilers.
- To handle events, you're supposed to make an enum for your controls and go through these EVENT_TABLE macros - it works, but generally it's a mess compared to nicer frameworks like Qt.
- Then and probably still today, OS X Retina support was completely broken. Not a great turnaround time - it was already a year after the release of Retina laptops.
wxWidgets looks like a reimplementation of MFC almost. This might be good for some people or bad for others. MFC is/was the Microsoft Foundation Classes, an OO framework for doing GUI development on Windows that dates back to 1992.
I'm guessing that when wxWidgets was originally written (also 1992!), the author(s) thought it would ease the transition from writing Windows-only apps to cross-platform apps. wxWidgets has a very similar class hierarchy and uses the same preprocessor techniques.
Not that knowing any of that background makes it any more pleasant to work with.
Well, it has its drawbacks, but if native controls are a requirement, what alternative cross-platform good enough frameworks do we have?
Agree about your points, except you can Connect (dynamically) event handlers as in Qt's connect. From wx 3.0 you can actually Bind any function (i.e. it is not necessary to derive from wxEvtHandler). I always preferred this to Qt's blind, non-cpp, runtime evaluated connect's. At least you get a compiler error when it is not possible to connect.
Yeah... That's the only thing keeping the world from adopting Go.
It is possible that Webkit will eventually become the UI container/framework of choice, however, and I'm sure at that point Qt will adapt. I'm still torn between them choosing QML (which is great!) vs HTML/CSS/JS purely for popularity reasons. I would wish for QML to win because it is a dream to work with.
Other than native controls and the potential DOM lag of a webkit interface, is there any particular reason why someone programming in Go, Python, Ruby, etc. would want to engage Qt; assuming a stable, working library?