As I view the problem, what's lacking is a GUI markup standard roughly comparable to HTML. HTML browsers were not originally meant to build full-on GUI's in, but the industry has accepted the habit of forcing them to "do" GUI's using convoluted tricks and giant JavaScript libraries.
By the way, the "GUI markup language" doesn't necessarily have to be XML-only. Maybe JSON or CSV versions can be defined also. However, XML is a good start: learn to walk before you run.
If the "industry" adopts them as a standard, then they could take off (and if not encumbered by intellectual property lawsuit risk). XUL also looked "too Webby" to me, closer aligned to HTML than desktop-like GUI's.
I'd beg to differ, XUL produced very clean native UI yet accepted styling with CSS years before I'd seen anything else like it. At the time I was writing Firefox addons and I was blown away but what I could do with it vs. WinForms or somesuch
FYI, XUL is being kept alive by the Pale Moon/Basilisk team, who has created a next-generation platform based on XUL called UXP (Unified XUL Platform).
Some part of the industry did; in MS shops a lot of XAML is used. The old MS would've pushed XAML for web applications a lot more, but the new is more of whatever the developer wants. There are people working on XAML everywhere (all platforms including web), especially in the Xamarin.Forms camp, but there is no force or adoption there. It's mostly WPF (and a bit of Xamarin) that uses XAML, but that's a large group still; I encounter it everywhere at partners/clients (usually Java runs on the servers 'in the basement' and some non trivial amount of WPF/Xamarin.Forms (XAML) (now with .NET Core where possible; even the .NET only shops do seem to like it) runs on the front facing systems).
Interesting. Thanks. On first impressions QML looks more suited toward multimedia applications than CRUD or business applications. But, we can test that theory...
So, instead of language bindings for the UI builder, you need an in-language implementation of or binding to a client for the GUI markup language output by the UI builder? While I like the idea of a generic UI markup languages, it sounds like you've replaced the problem you want to avoid with a bigger one.
Generic GUI API's that fit a wide variety of application programming languages has proven a very tricky task. I know of none that do it close to right.
Data structures and object models vary too much between languages. If you "solve" this by extracting out anything potentially programming-language-specific (such as variable types and data structure "types"), you end up with something that looks like a markup language anyhow (or at least a declarative data/attribute language).
I would say that Rebol did this very well with their builtin VIEW DSL. You can effortlessly build a very complex desktop app in this manner. If you scroll down a little bit you can see a lot of simple GUI apps like paint that require nearly zero boiler plate.
I think there has been a big miscommunication somewhere. I don't see what IDE's have to do with this. I'm thinking of say having a "draw button" command that works in any programming language similar to how just about any programming language can send and receive HTML to "have" a UI via a web browser. But, the markup language would be better suited to GUI's than HTML/CSS/DOM.
Note I am not against middle-ware that can translate a GUI markup language to and from "native" data structures/types. I use and make "HTML helpers" in specific application languages all the time so that I'm not communicating in raw HTML for specific common items.
By the way, the "GUI markup language" doesn't necessarily have to be XML-only. Maybe JSON or CSV versions can be defined also. However, XML is a good start: learn to walk before you run.
As far as how interaction and screen changes could be handled, see: http://wiki.c2.com/?GuiMarkupProposal
I particularly dig the 3-type "update" technique that uses "Attribute", "Tag", and "Delete" scope. (It's about half way down in the document.)