Not a fan of electron at all. But I think it points out the direction for the future of gui. There's a whole generation of new languages (rust, go, dart, D, ...) that wants to get into the gui-space and finding QT and GTK problematic. QT is known for "using every C++ feature", making it less than ideal for bindings. GTK is not very cross platform I think, and is criticized for beeing gnome-centric. Both toolkits are object-oriented, making them a poor fit for any language that is not. Something like mozilla's webrender could be used in a more language agnostic way (declerative, reactive), while having the support required for the gargantuan task of a graphics/toolkit backend.
Qt isn't known for "using every C++ feature" at all. Quite to the contrary, as far as C++ goes, Qt is stuck in the old times BEFORE modern C++. And it really shows in the architecture, memory management and syntax. In fact, lots of Qt's non-gui stuff is precisely about features that were missing in standard C++ at the time and later found their way there, leaving Qt with its old non-standard stuff (including containers, smart pointers, etc) and its raw pointers everywhere.
Making a wrapper for Qt is not really any more complicated by Qt being written in (old-style) C++ than if it had been written in C. In fact, lots of languages do have Qt wrappers. As for Qt being object oriented… well, while that might indeed have been a problem for a language that is not… all your examples (rust, go, dart, D, ...) are, so that's hardly the problem there. Also, as far as the declarative and reactive goes: Qt does do that as well, and way better than any browser-lib-based webrendering engine (including mozilla's)
The real pain point with Qt is with its licensing at least since Qt was bought by Digia.
Two points. Qt isn't using every C++ feature - it works fine without exceptions and generally feels fairly pedestrian to use (that's a feature). It is very much not a template hell like some parts of Boost.
Second, it has QML, which is a declarative UI framework with great runtime performance.
I'd like the pain-point parties (Apple, Microsoft) to just ship open-source linkable libraries of somekind in their app stores.
If OSX, Windows, and the mobile stores carried a common framework developers could target it would become a defacto UI standard since you could finally develop a cross-platform app that used 'native widgets' (at least a library that might already be installed) for every given platform, and which could have an OS prompt that asks to install it from a trusted source if they don't happen to have it.
What’s the need? For better or worse, app bundles tend to be huge these days; there’s no obstacle to embedding a few megabytes’ worth of GUI libraries in your app bundle, or just statically linking them into your executable. Heck, a lot of apps embed a 120MB+ Electron framework; that’s pushing it, but Qt is “only” <20MB of DLLs, or less if you statically link it. (A more focused GUI library could be much smaller.)
I’d love to see better cross-platform desktop apps. But I think the missing piece is for someone to write a good library that uses native widgets – not figuring out how to distribute that library.
For the record, I think Qt is reasonably good, but not native enough. On macOS, even QWidget often imitates native widgets (poorly) instead of using them; on top of that, QWidget as a whole has unfortunately been semi-deprecated, in favor of newer QML stuff that doesn’t even try to look native.
I hear this quite a lot and am always curious to know which bits of the QWidget hierarchy are insufficiently native on the Mac - I've run in to many problems with Qt on the Mac over the years but that hasn't really been one, though our current app doesn't really use native-looking widgets anyway.
As for QWidget being semi-deprecated, this is not the case. They made some noises in that direction around the time Qt 5 was being developed but I think they thought better of it, so it's alive and well and still being developed.
- Text fields are not backed by native NSTextViews, so automatic substitutions, spell checking, and the options you usually have in the right-click/Edit menu are all missing.
- Pop-up menus (but not top-menu-bar menus) are also custom, and the appearance and animations are way off. And there are some discrepancies in behavior:
a. Suppose you right-click and hold (which opens the right-click menu in a mode where you select menu items by releasing instead of clicking), then release while over a menu item that's either disabled or a submenu. With native menus, the menu gets dismissed; with Qt menus, it stays open. Sounds incredibly minor, right? But it's something I grew to subconsciously rely on, over years of using macOS. When I started using a Qt app, I kept instinctively trying to dismiss menus that way and getting frustrated when they stayed open.
b. If the mouse cursor leaves the menu area, native menus stop highlighting any item, while Qt menus keep highlighting whichever item was last highlighted. In the press-and-hold mode, this makes it seem like releasing the button might choose that item; it actually dismisses the menu, same as with native menus, but it's confusing.
Qt seems to be quite deliberately written in a super/subset of C++ that looks a great deal like Java with smart pointers. Which, coincidentally, also makes it possible to provide language projections without having to manually adapt each and every class.
There is essentially no way to implement modern (ie. what any user expects since Windows 95) UI toolkit as an immediate mode thing. It is not only about drawing stuff on screen and handling mostly mouse events. There are things like keyboard shortcuts, keyboard navigation, clipboard/cutbuffers/selections, automation and accessibility hooks...
I'm not sure I understand why you think there is no way to do that with an API designed in IMGUI style? IMGUI is a style of exposing UI API. There's no reason this can't be made with a IM-style UI.
You are comparing apple and oranges when comparing the feature set of a small UI system made by 1 person-ish vs something like Qt benefiting from decades of experiences and hundreds of devs.
