5 ms·

I've used Qt for several desktop apps, both using Widgets and QML; I never used the python bindings, always used the C++ libraries directly. Writing GUIs is no

I've used Qt for several desktop apps, both using Widgets and QML; I never used the python bindings, always used the C++ libraries directly. Writing GUIs is not a ton of fun for me (whether with Qt on desktop, native development on iOS and Android, or Flutter for mobile/desktop), but I wouldn't say Qt Widgets are worse than other stuff. I'd say it's definitely better that Android and iOS were a few years ago, before reactive programming became widespread. I didn't have a good experience with QML; I'd call it at most not great, not terrible. I've been using Flutter lately for a desktop app and the GUI part is more pleasant to write, for me (mainly because of the general "immediate mode/react" feel); if the app had a reasonably complex business logic I wouldn't want to write it in Dart though.

ZeroCool2u 5y ago
"... if the app had a reasonably complex business logic I wouldn't want to write it in Dart though." I'm surprised by this as I've been working on a pure Dart library lately and really enjoyed it. Anything in particular you dislike?
- grumpyprole 5y ago
  Not the OP, but Dart, although basically a 90's Java clone, is still superficially different enough that it needs to be learnt - so where's the payoff? It doesn't fix most of Java's issues: pervasive mutability, boilerplate, a kingdom of nouns, Tony Hoare's billion dollar mistake etc. There are many better Java++ languages out there; and this includes the roadmap for Java itself (pattern matching, sealed classes, data classes, fibers etc).
  - ZeroCool2u 5y ago
    Some fair points here. The differences that I've experienced have generally seemed very positive and it feels like significantly less boilerplate than Java. As for Tony Hoare's billion dollar mistake, I'm not sure if you've seen the information about Sound Null-Safety[1], but it's actually one of my favorite features about the language. Static analysis in Dart feels a little bit like Rust in that as you write code your IDE can provide smart suggestions and bugs are often found as you write instead of when you compile. Finally, I'll take the pub.dev[2] toolchain and build system over anything out there today besides Cargo. Plus, compiling to a single executable file without any dependencies that have to be installed on the deployment target is great. "There are many better Java++ languages out there." Any in particular you'd suggest? I'd definitely give it a shot if it blows Dart out of the water! [1]: https://dart.dev/null-safety https://dart.dev/null-safety [2]: https://pub.dev/ https://pub.dev/
    - grumpyprole 5y ago
      Ok, it looks like they've now retrofitted null safety, but why wasn't it designed in from the start? I can't help but feel this was always a Java-clone to avoid litigation, not any kind of innovative project. Kotlin looks like a good Java++ language (especially for Android); and Typescript would be the most pragmatic choice for web. But again, Dart is going to have to keep up even with modern Java. Regarding boilerplate, can Dart define a simple data class with equals and hashcode in one or two lines?
      - ZeroCool2u 5y ago
        I think you'll find that in many ways that today's Dart is very different from the earlier iterations people experienced in 1.x. You're right it wasn't designed in from the start, but I couldn't possibly say why. I can say it doesn't feel bolted on and it's definitely the default for all Dart code I've seen recently in the wild. Kotlin is certainly nice to write in, but all else being equal, if I can avoid the JVM and get easy AOT compilation, deployment, and distribution I'll take that every time. Typescript transpiles to JS, same as Dart, so that just seems like extra steps, but there are clearly advantages to sticking with regular JS frameworks over Flutter for the moment, so I won't argue that point. I'm really just talking about Dart here. Frankly, I haven't needed to implement such a basic data structure myself in Dart, but here's a whole book of examples of implementing common data structures[1]. They look pretty straight forward to me. You can also take a look at the Dart language tour.[2] [1]: https://www.raywenderlich.com/books/data-structures-algorithms-in-dart/v1.0/chapters/4-stacks#toc-chapter-010-anchor-002 https://www.raywenderlich.com/books/data-structures-algorith... [2]: https://dart.dev/guides/language/language-tour https://dart.dev/guides/language/language-tour
  - lultimouomo 5y ago
    Pretty much this. It has nullable types now, but it's still a meh java clone. On the plus side, I wouldn't say it really needs to be learned if you know Java (and maybe Kotlin or Swift, so that you are used to the ? operator). I wrote a couple of apps in Flutter, having never read even a single line about Dart. I picked it up by looking at the Flutter examples. One particularly annoying thing is that a whole lot of stuff is achieved through code generation (serialization, equality operators, ORM mapping, localization among others), and there are so many different way that code generation can be done - some automatic during the build, some that must be manually invoked. The build system seems really lacking.
ravenstine 5y ago
It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite. My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for. Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better. The solution to most things in Quick is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your Quick widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a Quick widget class because you just can't simply do that. For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a Quick widget only, rather that do the obvious thing of exposing it as a C++ class and providing a Quick widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods. But I realized that, at that point, there was no longer any point in using Quick if I was going to have to use some neat tricks in C++. So in just a day, I wrote a classic widget that implements the same WebView used in the Quick version, just without any of the QML crap. https://github.com/Ravenstine/qt-web-view-widget https://github.com/Ravenstine/qt-web-view-widget And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill. Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part. I wish they'd abandon QML/Quick and just focus on making the experience of writing completely native apps better. I also see no reason why the solution to mobile development can't simply be different sets of classic widgets that are mobile-specific.
dkersten 5y ago
I’ve personally had good experiences with both QWidgets based Qt (using C++) and QtQuick/QML.

ZeroCool2u 5y ago

"... if the app had a reasonably complex business logic I wouldn't want to write it in Dart though." I'm surprised by this as I've been working on a pure Dart library lately and really enjoyed it. Anything in particular you dislike?

grumpyprole 5y ago
Not the OP, but Dart, although basically a 90's Java clone, is still superficially different enough that it needs to be learnt - so where's the payoff? It doesn't fix most of Java's issues: pervasive mutability, boilerplate, a kingdom of nouns, Tony Hoare's billion dollar mistake etc. There are many better Java++ languages out there; and this includes the roadmap for Java itself (pattern matching, sealed classes, data classes, fibers etc).
- ZeroCool2u 5y ago
  Some fair points here. The differences that I've experienced have generally seemed very positive and it feels like significantly less boilerplate than Java. As for Tony Hoare's billion dollar mistake, I'm not sure if you've seen the information about Sound Null-Safety[1], but it's actually one of my favorite features about the language. Static analysis in Dart feels a little bit like Rust in that as you write code your IDE can provide smart suggestions and bugs are often found as you write instead of when you compile. Finally, I'll take the pub.dev[2] toolchain and build system over anything out there today besides Cargo. Plus, compiling to a single executable file without any dependencies that have to be installed on the deployment target is great. "There are many better Java++ languages out there." Any in particular you'd suggest? I'd definitely give it a shot if it blows Dart out of the water! [1]: https://dart.dev/null-safety https://dart.dev/null-safety [2]: https://pub.dev/ https://pub.dev/
  - grumpyprole 5y ago
    Ok, it looks like they've now retrofitted null safety, but why wasn't it designed in from the start? I can't help but feel this was always a Java-clone to avoid litigation, not any kind of innovative project. Kotlin looks like a good Java++ language (especially for Android); and Typescript would be the most pragmatic choice for web. But again, Dart is going to have to keep up even with modern Java. Regarding boilerplate, can Dart define a simple data class with equals and hashcode in one or two lines?
    - ZeroCool2u 5y ago
      I think you'll find that in many ways that today's Dart is very different from the earlier iterations people experienced in 1.x. You're right it wasn't designed in from the start, but I couldn't possibly say why. I can say it doesn't feel bolted on and it's definitely the default for all Dart code I've seen recently in the wild. Kotlin is certainly nice to write in, but all else being equal, if I can avoid the JVM and get easy AOT compilation, deployment, and distribution I'll take that every time. Typescript transpiles to JS, same as Dart, so that just seems like extra steps, but there are clearly advantages to sticking with regular JS frameworks over Flutter for the moment, so I won't argue that point. I'm really just talking about Dart here. Frankly, I haven't needed to implement such a basic data structure myself in Dart, but here's a whole book of examples of implementing common data structures[1]. They look pretty straight forward to me. You can also take a look at the Dart language tour.[2] [1]: https://www.raywenderlich.com/books/data-structures-algorithms-in-dart/v1.0/chapters/4-stacks#toc-chapter-010-anchor-002 https://www.raywenderlich.com/books/data-structures-algorith... [2]: https://dart.dev/guides/language/language-tour https://dart.dev/guides/language/language-tour
- lultimouomo 5y ago
  Pretty much this. It has nullable types now, but it's still a meh java clone. On the plus side, I wouldn't say it really needs to be learned if you know Java (and maybe Kotlin or Swift, so that you are used to the ? operator). I wrote a couple of apps in Flutter, having never read even a single line about Dart. I picked it up by looking at the Flutter examples. One particularly annoying thing is that a whole lot of stuff is achieved through code generation (serialization, equality operators, ORM mapping, localization among others), and there are so many different way that code generation can be done - some automatic during the build, some that must be manually invoked. The build system seems really lacking.

ravenstine 5y ago

It really confuses me how anyone would have anything good to say about QML. Qt taking that direction just seems like a panicked decision to try and compete with Electron when they should really be doing the exact opposite. My experience with QML/Quick is that while you get a little JavaScript runtime and a slightly less obtuse way of defining "widgets" and application layouts than the original Qt "forms", there are some clear drawbacks that make it a near non-starter for anything I've thought about using it for. Right out of the box, you have to use QML, which is a weird hybrid of language/markup paradigms, and it's a proprietary language. What designer knows QML? Probably f$#%& zero. Electron wins right out of the gate because what designers don't know at least something about HTML and CSS? Sure, if QML was that groundbreaking then maybe people would learn it, but it's owned by a company and it brings nothing new to the table that HTML and CSS can't do better. The solution to most things in Quick is to write JavaScript. I've been a JavaScript engineer for most of my career, but when you're writing a Qt application then the obvious place to do anything useful or complex is in the host language of C++ or Python. So what if you want to tie behavior between your Quick widget and a C++ library you either wrote yourself or have imported from a vendor? Well, you can kinda sorta do that, but it's hard to explain here; let's just say that tying a widget to C++ code is extremely clumsy, and good luck calling a function on a Quick widget class because you just can't simply do that. For instance, Qt provides a WebView widget, which was exactly what I needed recently. Uh oh, the decided to make it a Quick widget only, rather that do the obvious thing of exposing it as a C++ class and providing a Quick widget that wraps around it. Why did they do this? I guess it's because in the long term they think that they'll move away from classic widgets entirely. In any case, I wanted to call the `runJavaScript` method on the widget class without having to jump through hoops in QML. The only way to make that happen was to hack the build process to expose private methods. But I realized that, at that point, there was no longer any point in using Quick if I was going to have to use some neat tricks in C++. So in just a day, I wrote a classic widget that implements the same WebView used in the Quick version, just without any of the QML crap. https://github.com/Ravenstine/qt-web-view-widget https://github.com/Ravenstine/qt-web-view-widget And yeah, Qt does provide some form of a WebView in as a classic widget but, guess what, it involves bundling a browser runtime rather than using the browser engine of the host OS. Makes sense if you need more of the browser APIs exposed, but if all you want to do is show some simple things on a webpage and call JS from C++, then going through the effort of compiling Qt with support for that browser engine is overkill. Overall, I don't mind most things about Qt. Despite how overcomplicated some of it is, it does what I want, which is to allow me to write native desktop apps without needing to invest much of my knowledge in OS-specifics. I like that I can use their Bluetooth library and, besides some quirks with how macOS handles device identifiers, I can compile it on other platforms and it will work for the most part. I wish they'd abandon QML/Quick and just focus on making the experience of writing completely native apps better. I also see no reason why the solution to mobile development can't simply be different sets of classic widgets that are mobile-specific.

dkersten 5y ago

I’ve personally had good experiences with both QWidgets based Qt (using C++) and QtQuick/QML.