4 ms·

Here's a general purpose decision tree for deciding what to use for graphical applications. mobile? -> Ask someone else, not me. desktop? po

Here's a general purpose decision tree for deciding what to use for graphical applications. mobile? -> Ask someone else, not me. desktop? portable? yes: -> Qt needs to be fast? Lots of heavy lifting? yes: -> Use "simple C++" no: -> Use Python no: linux: -> unless specifically for gnome, Qt. mac: -> Mac. windows: -> C# and MS's flavour-of-the-day framework If you really dislike C# for some reason, Qt. none of the above: -> probably Qt embedded? -> Qt. What-part-of-Qt-to-use A "productive" application, something people will work with for lots of hours and just need to get stuff done. -> probably Qt Widgets A "special snowflake fancy" application that should look special and very distinguished -> probably Qt Quick. This is going to be more work, if it's a "productive" application as well. Embedded or quasi-mobile applications mostly used with a touchscreen or other limited inputs -> Qt Quick.

jacobush 8y ago
Embedded? Can your end-user relink your app with their own version of QT? Yes - fine, use QT. No? Is it OK to pay for the commercial version of QT? Yes - fine, use QT. No - look elsewhere.
- blattimwind 8y ago
  If you're building commercial products, then "it'd be great if everything was free because that's more profit for me", but usually it doesn't work out that way. That being said, there is still a much cheaper commercial version of Qt for smaller businesses ("start-up license").
  - jacobush 8y ago
    Oh wow, way to over react. How about - our dirt cheap embedded product can not bear the cost of the (great BTW) QT library so we have to make do with something else, perhaps our own polished turd. Or - we could easily afford it except that it's neigh impossible for us on the dev level to get an audience with the powers higher up in the company imbued with the ability to bless payments for software. AKA corporate spend. In times of budget freeze, even a request for such frivolous expenditure can usually not be done without the proper ritual sacrifice of someone in middle management. It's really hard to get volunteers. Known workarounds are to start developing in QT (or whatever) and postpone the ritual sacrifice of middle management personell until the shit hits the fan AKA release date, or to just use something else. (It's possible a smashing success at release may make it easier to forgive and forget and not look too hard into which middle management drone should take the blame the licensing slip up.) Another workaround is to pretend that LGPL = MIT for all intents and purposes but that is frowned upon in certain corporations priding themselves with such things as ethics and licensing guidelines.
samlewis 8y ago
Asking out of mostly ignorance, but is Qt still relevant in 2018? I've noticed that even for standalone graphical applications, it's becoming more and more common to use webapps - either served locally and accessed through a browser, or through something like electron.
- fredsir 8y ago
  Lots of people loathe this trend, so yes, I'd say, anything but web apps packaged as platform apps are relevant.
- some_account 8y ago
  Depends on the app. I run some things in the browser but if there is a native app for something, it's always more responsive and faster to use. Qt is very fast and very cross platform and Qt 5 together with Python is coming in a new form: https://www.qt.io/qt-for-python https://www.qt.io/qt-for-python

jacobush 8y ago

Embedded? Can your end-user relink your app with their own version of QT? Yes - fine, use QT. No? Is it OK to pay for the commercial version of QT? Yes - fine, use QT. No - look elsewhere.

blattimwind 8y ago
If you're building commercial products, then "it'd be great if everything was free because that's more profit for me", but usually it doesn't work out that way. That being said, there is still a much cheaper commercial version of Qt for smaller businesses ("start-up license").
- jacobush 8y ago
  Oh wow, way to over react. How about - our dirt cheap embedded product can not bear the cost of the (great BTW) QT library so we have to make do with something else, perhaps our own polished turd. Or - we could easily afford it except that it's neigh impossible for us on the dev level to get an audience with the powers higher up in the company imbued with the ability to bless payments for software. AKA corporate spend. In times of budget freeze, even a request for such frivolous expenditure can usually not be done without the proper ritual sacrifice of someone in middle management. It's really hard to get volunteers. Known workarounds are to start developing in QT (or whatever) and postpone the ritual sacrifice of middle management personell until the shit hits the fan AKA release date, or to just use something else. (It's possible a smashing success at release may make it easier to forgive and forget and not look too hard into which middle management drone should take the blame the licensing slip up.) Another workaround is to pretend that LGPL = MIT for all intents and purposes but that is frowned upon in certain corporations priding themselves with such things as ethics and licensing guidelines.

samlewis 8y ago

Asking out of mostly ignorance, but is Qt still relevant in 2018? I've noticed that even for standalone graphical applications, it's becoming more and more common to use webapps - either served locally and accessed through a browser, or through something like electron.

fredsir 8y ago
Lots of people loathe this trend, so yes, I'd say, anything but web apps packaged as platform apps are relevant.
some_account 8y ago
Depends on the app. I run some things in the browser but if there is a native app for something, it's always more responsive and faster to use. Qt is very fast and very cross platform and Qt 5 together with Python is coming in a new form: https://www.qt.io/qt-for-python https://www.qt.io/qt-for-python