4 ms·

Just a bit off topic, but are there many people still using Qt to write desktop software ? I mean, Qt's not React or Angular, but I find it very easy to work wi

by wiz21c 9y ago

Just a bit off topic, but are there many people still using Qt to write desktop software ? I mean, Qt's not React or Angular, but I find it very easy to work with as long as there is not much asynchronicity required...

cheez 9y ago
Writing async Qt is pretty easy, take a look at QFuture
mherrmann 9y ago
I'm using PyQt to develop a file manager [1]. Pretty happy with it so far. I chose it over Electron because of performance [2]. [1]: https://fman.io https://fman.io [2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...
- jackmott 9y ago
  thank you
stephen_g 9y ago
We use it to write little applications for communicating with embedded devices for factory testing, calibration, etc. Generally PyQt for the little ones and then full C++ for the mode complex ones.
gcp 9y ago
Assuming you require portability, the other options are generally all Chrome-based, so if you like you application to not look like shit, I mean, look native... There's only really wxWidgets in this space, which is order of magnitude smaller. I guess on Windows there's .NET if you don't care for other platforms as much. Do people still use other toolkits for writing native C++ apps with GUIs? MFC? Native win32 code?
- roel_v 9y ago
  MFC here! When you use it as a thin wrapper around win32 it's not bad. Actually I quite like it, but that's probably at least partly because I've been using it for so long and I know the warts. I'm convinced that the time I spend on working around its age and oldschool architecture is less than what I would have spend had I switched/"upgraded" toolkits every 3-5 years as seems to be the common practise. Same goes for using C++, btw.
  - gcp 9y ago
    I don't think native toolkits (well, major ones that gain adoption) are coming out much in the C++ space. I really only know the ones I mentioned!
    - roel_v 9y ago
      Oh in the Windos sphere there was Windows Forms, and XAML, and some others thatvI forgot; and html/css based ones (there were some 15+ years ago!); and some other 'universal' ones like wxWidgets but not open source existed years ago. New ones coming out not so much, no.
  - mmargerum 9y ago
    I loved WTL when I was building native desktop and windows ce apps.
inlineint 9y ago
I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way on other platforms, so although it compiles on, say, Mac, it doesn't fully work). It was started with Qt4 10 years ago, then it was ported to Qt5. So I think I can share my perception of Qt. The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads. However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT. Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app. [1] http://qstardict.ylsoftware.com http://qstardict.ylsoftware.com
dazzawazza 9y ago
yep, level editor for our video game is written in C++/Qt. Wouldn't consider anything else really.
rhodysurf 9y ago
yup a bunch of DOD software has moved to Qt to not be locked into using only Windows long term.
- majewsky 9y ago
  DOD = Department of Defense?
  - rhodysurf 9y ago
    Late reply, but yes
joezydeco 9y ago
Yup. I write embedded systems in Qt that sometimes need PC-based counterpart programs, typically configuration editors. When I write the PC side of the system I can usually port the necessary support code right out of the embedded project in a few minutes. I'll also build PC versions of the embedded GUIs for sales demonstrations. My sales team loves that.

by wiz21c 9y ago

cheez 9y ago

Writing async Qt is pretty easy, take a look at QFuture

mherrmann 9y ago

I'm using PyQt to develop a file manager [1]. Pretty happy with it so far. I chose it over Electron because of performance [2]. [1]: https://fman.io https://fman.io [2]: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...

jackmott 9y ago
thank you

stephen_g 9y ago

We use it to write little applications for communicating with embedded devices for factory testing, calibration, etc. Generally PyQt for the little ones and then full C++ for the mode complex ones.

gcp 9y ago

Assuming you require portability, the other options are generally all Chrome-based, so if you like you application to not look like shit, I mean, look native... There's only really wxWidgets in this space, which is order of magnitude smaller. I guess on Windows there's .NET if you don't care for other platforms as much. Do people still use other toolkits for writing native C++ apps with GUIs? MFC? Native win32 code?

roel_v 9y ago
MFC here! When you use it as a thin wrapper around win32 it's not bad. Actually I quite like it, but that's probably at least partly because I've been using it for so long and I know the warts. I'm convinced that the time I spend on working around its age and oldschool architecture is less than what I would have spend had I switched/"upgraded" toolkits every 3-5 years as seems to be the common practise. Same goes for using C++, btw.
- gcp 9y ago
  I don't think native toolkits (well, major ones that gain adoption) are coming out much in the C++ space. I really only know the ones I mentioned!
  - roel_v 9y ago
    Oh in the Windos sphere there was Windows Forms, and XAML, and some others thatvI forgot; and html/css based ones (there were some 15+ years ago!); and some other 'universal' ones like wxWidgets but not open source existed years ago. New ones coming out not so much, no.
- mmargerum 9y ago
  I loved WTL when I was building native desktop and windows ce apps.

inlineint 9y ago

I (actually not only me but also a few other guys) wrote an open source GUI dictionary for Linux [1] (it uses Qt selection features that don't work the same way on other platforms, so although it compiles on, say, Mac, it doesn't fully work). It was started with Qt4 10 years ago, then it was ported to Qt5. So I think I can share my perception of Qt. The framework is very solid, the components are easy to combine and in general, once you get used to it, it becomes quite easy to work with them. The resulting app is very performant and has low memory consumption in comparison to JS-based apps. Also, adding asynchronicity is actually not hard, at least for things like HTTP requests, as you can use Qt signal/slot system to receive events asynchronously so that in simple cases it is not necessary to mess up with threads. However, the developer productivity is, in my perception, is a somewhat less than with modern JS frameworks. Not 10x less, but a bit less. I think one of the issues is C++ itself: after changes in the code, it is necessary to not only rebuild but rerun the app, and in general writing C++ code is something that requires some attention as otherwise, it is possible to have SEGFAULT somewhere in your app and then spend time looking for the place in your new code that causes this SEGFAULT. Note that I'm talking here only about classical QtWidget/C++ apps, not QtQuick ones. I think productivity with the second ones should be better. However, one might argue that if you started to write your code in Javascript, it's better to do it in a way that allows you to have the same code running natively in browser (QtQuick experimentally runs in it, but it is experimental and not mainstream), so that you can share components and code for example between your site and your desktop app. [1] http://qstardict.ylsoftware.com http://qstardict.ylsoftware.com

dazzawazza 9y ago

yep, level editor for our video game is written in C++/Qt. Wouldn't consider anything else really.

rhodysurf 9y ago

yup a bunch of DOD software has moved to Qt to not be locked into using only Windows long term.

majewsky 9y ago
DOD = Department of Defense?
- rhodysurf 9y ago
  Late reply, but yes

joezydeco 9y ago

Yup. I write embedded systems in Qt that sometimes need PC-based counterpart programs, typically configuration editors. When I write the PC side of the system I can usually port the necessary support code right out of the embedded project in a few minutes. I'll also build PC versions of the embedded GUIs for sales demonstrations. My sales team loves that.