[weberc2]

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

[jcelerier]

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

[weberc2]

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.

[jcelerier]

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

[weberc2]

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.

[jcelerier]

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

[weberc2]

Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.

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

My point does make sense, you're just missing it.

First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.

Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.