Last time I checked (a year ago), only Qt supported all 5 major native platorms: Linux/Mac/Windows and Android/iOS. Maybe also React Native, if you count [1] (Qt backend) or [2] (libui). Now it looks like Flutter started to support desktop recently. And that's it, I think.
As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for which this can be said (except for the browser-based solutions, of course).
> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator)
Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.
This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break.
That's what you get with Qt absent the moc (meta object compiler).
Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.
So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.
> This misses my point. If I create a language and assign different semantics to the Python AST,
but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.
C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.
> Your editor cannot autocomplete those signals/slots like Qt Creator.
what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox.
Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, hell even notepad++ in all its "non-intelligence" manages to.
> Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.
I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.
I don't think that really excuses the use of Electron. Cross-platform GUI frameworks like Qt/GTK+ already exist to resolve this issue. This problem was already solved before Electron came around. All Electron did was lower the bar.
[1]: https://github.com/status-im/react-native-desktop [2]: https://github.com/kusti8/proton-native