4 ms·

Qt is an awesome framework, but I feel like most of their promo material really makes you work to figure out what is going on... I still see people get confused

Qt is an awesome framework, but I feel like most of their promo material really makes you work to figure out what is going on... I still see people get confused at QWidgets vs. QtQuick and the various tradeoffs.

symlinkk 10y ago
seriously, their naming scheme is so confusing: Qt Widgets: produces "classic" almost-native looking applications for Windows, macOS, and Linux. think lists, treeviews, menus, dialogs. C++ API Qt Quick Controls: like Qt Widgets, but with a QML (a declarative markup language) API Qt Quick Controls 2: doesn't try to look native on any platform, instead you create your own look and feel or use one of their pre-made themes (they have a Material design theme for instance). end result looks a lot like Electron applications. I believe these run on iOS and Android, as well as Windows, macOS, and Linux. QML API Qt Quick: umbrella term for both of the previous categories to make things worse there's very little guidance on what type of application each should be used for, and it seems like a lot of the work in the recent Qt releases has been focused on Qt Quick, making me wonder if Qt Widgets will be considered deprecated soon.
- pjmlp 10y ago
  I get the feeling they are trying to cater to the Electron generation and hence focusing on QML and related technology. Many new APIs are indeed QML only, like support for device and mobile UIs.
  - zerr 10y ago
    At the expense of alienating C++ devs.
    - pjmlp 10y ago
      I just tried to use it back in the 5.4 days and discovered that C++ Widgets weren't an option for mobile devices, which is still the case, now with their QML focus. https://bugreports.qt.io/browse/QTBUG-42491 https://bugreports.qt.io/browse/QTBUG-42491 Ended up using a mix of Java, C++/CX and C++ instead of Qt. However, with every GUI toolkit pushing C++ down the infrastructure alongside something more productive to the upper layers, pure C++ devs need to get used to being polyglot for UI code. I doubt we will see again a pure 100% C++ GUI toolkit earning the hearts of the masses, specially if you look at what is available from Apple, Google, Microsoft and Qt.
      - gcp 10y ago
        The real problem IMHO is that making a "native" yet "crossplatform" UI has become essentially impossible. You need to re-code the application for every platform. Which makes it understandable that people just go "fuck this, I'm making a webpage".
        pjmlp 10y ago
        You don't need to fully re-code the application for every platform., I was doing cross-platform before Qt even existed, back in the 16 bit days, even in Assembly between platforms with the same processors. The point is that you need to properly layer the common code from the platform specific code, from day one. Also writing web apps, usually means "write once debug everywhere" due to the differences between browsers and rendering engines. And in some platforms, specially embedded ones, it is back to the days of "alert()".
        majewsky 10y ago
        Say what you will, printf-debugging never dies.
        gcp 10y ago
        I'm not sure if you understood the "native yet crossplatform" part. I'm not talking about native code, I'm talking about a native looking UI. In other words, Win32 on Windows, GTK/Qt on Linux, etc. Instead of Electron or QML. Obviously you don't need to rewrite the backend unless you're an idiot. But in some applications, the frontend part is huge.
        pjmlp 10y ago
        Sure I did, hence why I mentioned it needs to be done from day one. The whole set of abstraction modules, need to be properly defined so that the whole architecture is able to use the best patterns from each platform without feeling a kludge. How do you think many of us wrote portable software across Atari, Amiga, Acorn, Mac and PC? One needs to abstract platform concept's like opening files into a modular API that accepts only the application relevant parameters, then provide an implementation using the platform specific UI toolkit. It was harder to do with the Assembly applications, due to the hardware differences, but it was still possible to keep some code for those that shared the same processor architecture. Still using a similar modular approach. Here using macro assemblers was a big help.
    - jug 10y ago
      At the risk of "cursing in the church", I think honestly UI work doesn't seem like the purpose of a systems language like C++ though, rather to give liberties in memory management to optimize intensive algorithms etc. I don't think much would be lost in performance with a C++ backed QML based interface, but much might be gained in productivity in the long run, discounting relearning.
joe563323 10y ago
Oh Yes their marketing sucks but products are awesome. QtCreator is one of the best c++ editor and debugger. But the marketing just sucks.

symlinkk 10y ago

seriously, their naming scheme is so confusing: Qt Widgets: produces "classic" almost-native looking applications for Windows, macOS, and Linux. think lists, treeviews, menus, dialogs. C++ API Qt Quick Controls: like Qt Widgets, but with a QML (a declarative markup language) API Qt Quick Controls 2: doesn't try to look native on any platform, instead you create your own look and feel or use one of their pre-made themes (they have a Material design theme for instance). end result looks a lot like Electron applications. I believe these run on iOS and Android, as well as Windows, macOS, and Linux. QML API Qt Quick: umbrella term for both of the previous categories to make things worse there's very little guidance on what type of application each should be used for, and it seems like a lot of the work in the recent Qt releases has been focused on Qt Quick, making me wonder if Qt Widgets will be considered deprecated soon.

pjmlp 10y ago
I get the feeling they are trying to cater to the Electron generation and hence focusing on QML and related technology. Many new APIs are indeed QML only, like support for device and mobile UIs.
- zerr 10y ago
  At the expense of alienating C++ devs.
  - pjmlp 10y ago
    I just tried to use it back in the 5.4 days and discovered that C++ Widgets weren't an option for mobile devices, which is still the case, now with their QML focus. https://bugreports.qt.io/browse/QTBUG-42491 https://bugreports.qt.io/browse/QTBUG-42491 Ended up using a mix of Java, C++/CX and C++ instead of Qt. However, with every GUI toolkit pushing C++ down the infrastructure alongside something more productive to the upper layers, pure C++ devs need to get used to being polyglot for UI code. I doubt we will see again a pure 100% C++ GUI toolkit earning the hearts of the masses, specially if you look at what is available from Apple, Google, Microsoft and Qt.
    - gcp 10y ago
      The real problem IMHO is that making a "native" yet "crossplatform" UI has become essentially impossible. You need to re-code the application for every platform. Which makes it understandable that people just go "fuck this, I'm making a webpage".
      - pjmlp 10y ago
        You don't need to fully re-code the application for every platform., I was doing cross-platform before Qt even existed, back in the 16 bit days, even in Assembly between platforms with the same processors. The point is that you need to properly layer the common code from the platform specific code, from day one. Also writing web apps, usually means "write once debug everywhere" due to the differences between browsers and rendering engines. And in some platforms, specially embedded ones, it is back to the days of "alert()".
        majewsky 10y ago
        Say what you will, printf-debugging never dies.
        gcp 10y ago
        I'm not sure if you understood the "native yet crossplatform" part. I'm not talking about native code, I'm talking about a native looking UI. In other words, Win32 on Windows, GTK/Qt on Linux, etc. Instead of Electron or QML. Obviously you don't need to rewrite the backend unless you're an idiot. But in some applications, the frontend part is huge.
        pjmlp 10y ago
        Sure I did, hence why I mentioned it needs to be done from day one. The whole set of abstraction modules, need to be properly defined so that the whole architecture is able to use the best patterns from each platform without feeling a kludge. How do you think many of us wrote portable software across Atari, Amiga, Acorn, Mac and PC? One needs to abstract platform concept's like opening files into a modular API that accepts only the application relevant parameters, then provide an implementation using the platform specific UI toolkit. It was harder to do with the Assembly applications, due to the hardware differences, but it was still possible to keep some code for those that shared the same processor architecture. Still using a similar modular approach. Here using macro assemblers was a big help.
  - jug 10y ago
    At the risk of "cursing in the church", I think honestly UI work doesn't seem like the purpose of a systems language like C++ though, rather to give liberties in memory management to optimize intensive algorithms etc. I don't think much would be lost in performance with a C++ backed QML based interface, but much might be gained in productivity in the long run, discounting relearning.

joe563323 10y ago

Oh Yes their marketing sucks but products are awesome. QtCreator is one of the best c++ editor and debugger. But the marketing just sucks.