4 ms·

They're both C++ though. Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language.

by jmnicolas 4y ago

FpUser 4y ago
Try Lazarus FreePascal IDE. Has extensive GUI you can design visually
sho_hn 4y ago
GTK+ is C. There's C++ bindings (gtkmm), but they don't have a lot of uptake.
lelanthran 4y ago
> They're both C++ though. One of them is. > Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language. There's none, because all the linux GUI toolkit developers are "sane" enough to make the toolkit x-platform. If you're looking for "something that runs on linux, and linux only, and nowhere else" you are not going to find anything the way you find "something that runs on windows, and windows only, and nowhere else".
- favsq 4y ago
  >One of them is. None of them I'd say. I'd argue moc is not C++
  - sho_hn 4y ago
    There's a lot of overstated FUD about the moc. It's a preprocessor that expands a few macro strings into relatively simple boilerplate C++. Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++. The macro incantations aren't massively complicated and mostly are simple labels placed in header files; body code rarely uses anything moc-related these days. Compared to the crazy stuff Microsoft has done over the years within and on top of C++ on their platform, Qt's moc is barely a footnote. I respect not liking it, and I totally get the appeal of doing the same thing with tools built directly into the language (which to this day aren't fully comparable, and are mostly recent - check into the verdigris project for a solid and interesting take on attempting this), but it's a reasonably straight-forward approach to the problems it solves.
    - simplotek 4y ago
      > Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++. It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it. > Compared to the crazy stuff Microsoft has done over the years (...) Microsoft did a fantastic job with it's GUI frameworks. WPF is a stellar example of getting most things right. It's astounding how views are so trivial with WPF. XAML voodoo has it's critics but no one praising Qt would ever dare point a finger at XAML.
      - sho_hn 4y ago
        > It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it. You have to compare those drawbacks directly to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. Yes, perhaps optimizing the compilers would be nicer. > You have to compare those drawbacks to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully). There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies, while it's much easier to inadvertently write non-portable C++ with many other frameworks. Yes, it's a whatboutism (which I hope to have compensated for with many other detailed comments in the thread), but this double standard tends to irk me.
        simplotek 4y ago
        > You have to compare those drawbacks directly to the alternatives, though. It's ok to claim that Qt's MOC optimizes for developer experience,and all other tradeoffs are acceptable. > I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. This doesn't really matter. It's not just the MOC. Using Qt UI form files forces UIC into the picture, which also fails to be cached. > Yes, perhaps optimizing the compilers would be nicer. The compiler is not the problem. Obviously. WPF also uses code generators and it's not plagued with long build times. > Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully). This reads like whataboutism, and fails to address Qt's problems. > There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies I never saw that once, not do I understand why that is relevant.
  - dekhn 4y ago
    moc is the part of C++ the standards folks didn't see a need to integrate, but it should have always been there. Since all it does is take syntactic sugar and output more C++, it's clearly C++. of course, C++ eventually gained the ability to implement moc natively using a more general solution. to me, moc and the Qt base classes sort of round out C++ to me in a way that is better than the alternatives. I can imagine an entire world of application development based on Qt C++ base, and in fact I've written a few network servers this way. Simply having event loops with message passing built-in makes programming that much more enjoyable for me.
  - pjmlp 4y ago
    Just like many GCC and clang extensions aren't neither C nor C++, and they even get praised for.
- zorr 4y ago
  GTK has bindings to modern languages. The gtk-rs project is actively working on Rust bindings. I'm personally working with some others on Kotlin Native bindings and I know a new JVM effort is in progress using the new JVM FFI capabilities.
BearOso 4y ago
Gtk is C, but it's introspected in a way that it generates really good bindings for other languages. gtkmm and gtk-rs are really good. Qt is C++ through and through. Even more so because of its MOC. It's really hard to port to other languages. If we wanted a standard toolkit for Linux, it'd have to be written C to be compatible with most FFIs. The problem with Gtk is it's in coalition with Gnome, and its developers shun anything not fitting that scope.
- sho_hn 4y ago
  > Even more so because of its MOC. Ho-humm, I'd argue that specific point. The meta-object system adds introspection and reflection, and helps it get e.g. fantastic Python bindings. Various other bindings are also basically built around wrapping QObject+QMetaObject. Yes, binding Qt is anyway harder than GTK's C API. But not because of the MOC.
  - BearOso 4y ago
    That's an interesting point. I hadn't thought about the MOC helping introspection.
- cglong 4y ago
  Having never written using any of these technologies, I was wondering how ergonomic GTK would be in Rust. Isn't GTK very object-oriented in its design?
  - zorr 4y ago
    Check out the gtk-rs project which provides the Rust bindings.
smallstepforman 4y ago
> They're both C++ though. I’d argue that Qt API is pre-C++98, ie. pre std template library. Qt uses its own classes (vector, string, etc) instead of std template library. Even the MOC can be eliminated with the STL. Its an ancient API which is separate from modern post C++11. They’ve tried adding some STL and C++11 concepts, but they have millions of lines of legacy code to support, so its just more layers and bloat.
- sho_hn 4y ago
  You're not completely wrong, but I think this overstating things by a lot. I'll grant you the containers for example, but you can generally use STL algorithms with them. And plenty of old ways of doing things have left modern Qt-based codebases and moved to more modern ways of doing things, including a fair amount of moc macro usage (and yes, you can remove the moc these days, but it has different perf characteristics - cf. the verdigris project). The community around Qt is pretty active at adopting modern C++, e.g. imho https://github.com/danvratil/qcoro https://github.com/danvratil/qcoro is leading work. I'm glad that folks clamor for keeping things fresh, but every 30 year old project is going to span a few minor revolutions along the way.
- pjmlp 4y ago
  It is still C++ and in many aspects, much better than the current trends on the standard library design. Also, alongside VCL/Firemonkey, miles ahead of any C++ UI framework produced by Microsoft, WinDev just has no taste in doing GUI tooling for C++ developers.

They're both C++ though. Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language.

FpUser 4y ago

Try Lazarus FreePascal IDE. Has extensive GUI you can design visually

sho_hn 4y ago

GTK+ is C. There's C++ bindings (gtkmm), but they don't have a lot of uptake.

lelanthran 4y ago

> They're both C++ though. One of them is. > Bindings aren't ideal, I wish there was a native Linux gui toolkit with a "sane" language. There's none, because all the linux GUI toolkit developers are "sane" enough to make the toolkit x-platform. If you're looking for "something that runs on linux, and linux only, and nowhere else" you are not going to find anything the way you find "something that runs on windows, and windows only, and nowhere else".

favsq 4y ago
>One of them is. None of them I'd say. I'd argue moc is not C++
- sho_hn 4y ago
  There's a lot of overstated FUD about the moc. It's a preprocessor that expands a few macro strings into relatively simple boilerplate C++. Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++. The macro incantations aren't massively complicated and mostly are simple labels placed in header files; body code rarely uses anything moc-related these days. Compared to the crazy stuff Microsoft has done over the years within and on top of C++ on their platform, Qt's moc is barely a footnote. I respect not liking it, and I totally get the appeal of doing the same thing with tools built directly into the language (which to this day aren't fully comparable, and are mostly recent - check into the verdigris project for a solid and interesting take on attempting this), but it's a reasonably straight-forward approach to the problems it solves.
  - simplotek 4y ago
    > Yes, it's a separate little preprocessor binary instead of using C++'s built-in macro system, but the concept itself is not foreign to C++. It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it. > Compared to the crazy stuff Microsoft has done over the years (...) Microsoft did a fantastic job with it's GUI frameworks. WPF is a stellar example of getting most things right. It's astounding how views are so trivial with WPF. XAML voodoo has it's critics but no one praising Qt would ever dare point a finger at XAML.
    - sho_hn 4y ago
      > It does have it's drawbacks. The MOC heavily penalizes build times, and build caching tools like ccache don't work out of the box with it. So not only does the MOC worsens builds, it also prevents basic optimizations from mitigating it. You have to compare those drawbacks directly to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. Yes, perhaps optimizing the compilers would be nicer. > You have to compare those drawbacks to the alternatives, though. I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully). There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies, while it's much easier to inadvertently write non-portable C++ with many other frameworks. Yes, it's a whatboutism (which I hope to have compensated for with many other detailed comments in the thread), but this double standard tends to irk me.
      - simplotek 4y ago
        > You have to compare those drawbacks directly to the alternatives, though. It's ok to claim that Qt's MOC optimizes for developer experience,and all other tradeoffs are acceptable. > I don't have numbers to cite, but I think the attempts at replacing the moc with newer C++ lang features also usually didn't exactly hit the compiler fast paths. This doesn't really matter. It's not just the MOC. Using Qt UI form files forces UIC into the picture, which also fails to be cached. > Yes, perhaps optimizing the compilers would be nicer. The compiler is not the problem. Obviously. WPF also uses code generators and it's not plagued with long build times. > Maybe so, but this is not what my comment is about. What I'm saying is that MS has made much more invasive changes to C++ as a language than Qt has in its platforms or frameworks, e.g. compiler-backed extended and different behavior. Or look at C++/CX (since phased out, thankfully). This reads like whataboutism, and fails to address Qt's problems. > There's a lot of "If you're using Qt you're not using C++!!1" FUD to confuse newbies I never saw that once, not do I understand why that is relevant.
- dekhn 4y ago
  moc is the part of C++ the standards folks didn't see a need to integrate, but it should have always been there. Since all it does is take syntactic sugar and output more C++, it's clearly C++. of course, C++ eventually gained the ability to implement moc natively using a more general solution. to me, moc and the Qt base classes sort of round out C++ to me in a way that is better than the alternatives. I can imagine an entire world of application development based on Qt C++ base, and in fact I've written a few network servers this way. Simply having event loops with message passing built-in makes programming that much more enjoyable for me.
- pjmlp 4y ago
  Just like many GCC and clang extensions aren't neither C nor C++, and they even get praised for.
zorr 4y ago
GTK has bindings to modern languages. The gtk-rs project is actively working on Rust bindings. I'm personally working with some others on Kotlin Native bindings and I know a new JVM effort is in progress using the new JVM FFI capabilities.

BearOso 4y ago

Gtk is C, but it's introspected in a way that it generates really good bindings for other languages. gtkmm and gtk-rs are really good. Qt is C++ through and through. Even more so because of its MOC. It's really hard to port to other languages. If we wanted a standard toolkit for Linux, it'd have to be written C to be compatible with most FFIs. The problem with Gtk is it's in coalition with Gnome, and its developers shun anything not fitting that scope.

sho_hn 4y ago
> Even more so because of its MOC. Ho-humm, I'd argue that specific point. The meta-object system adds introspection and reflection, and helps it get e.g. fantastic Python bindings. Various other bindings are also basically built around wrapping QObject+QMetaObject. Yes, binding Qt is anyway harder than GTK's C API. But not because of the MOC.
- BearOso 4y ago
  That's an interesting point. I hadn't thought about the MOC helping introspection.
cglong 4y ago
Having never written using any of these technologies, I was wondering how ergonomic GTK would be in Rust. Isn't GTK very object-oriented in its design?
- zorr 4y ago
  Check out the gtk-rs project which provides the Rust bindings.

smallstepforman 4y ago

> They're both C++ though. I’d argue that Qt API is pre-C++98, ie. pre std template library. Qt uses its own classes (vector, string, etc) instead of std template library. Even the MOC can be eliminated with the STL. Its an ancient API which is separate from modern post C++11. They’ve tried adding some STL and C++11 concepts, but they have millions of lines of legacy code to support, so its just more layers and bloat.

sho_hn 4y ago
You're not completely wrong, but I think this overstating things by a lot. I'll grant you the containers for example, but you can generally use STL algorithms with them. And plenty of old ways of doing things have left modern Qt-based codebases and moved to more modern ways of doing things, including a fair amount of moc macro usage (and yes, you can remove the moc these days, but it has different perf characteristics - cf. the verdigris project). The community around Qt is pretty active at adopting modern C++, e.g. imho https://github.com/danvratil/qcoro https://github.com/danvratil/qcoro is leading work. I'm glad that folks clamor for keeping things fresh, but every 30 year old project is going to span a few minor revolutions along the way.
pjmlp 4y ago
It is still C++ and in many aspects, much better than the current trends on the standard library design. Also, alongside VCL/Firemonkey, miles ahead of any C++ UI framework produced by Microsoft, WinDev just has no taste in doing GUI tooling for C++ developers.