5 ms·

You mean QML? It's weird to see all of the C++ API reduced to a chapter. I've used Qt for years and QWidgets from C++ is all I've used.

by sjvpv 8y ago

hellofunk 8y ago
QWidgets are not under active development, and the future is QML. QWidgets will likely only receive maintenance fixes going forward. Time to join the future!
- 781 8y ago
  QML is just a teaser. Once you taste it you'll want the real thing and you'll move to Electron.
  - discreteevent 8y ago
    I had the opposite experience. Each to their own.
  - justinclift 8y ago
    The browser-application-pretending-to-be-a-desktop-application things I've seen don't handle multiple windows correctly, and most of them have problems with multi-key custom keyboard+mouse actions. :( Does Electron handle those scenarios well?
- Longhanks 8y ago
  According to the 2019 roadmap, QWidgets is very much not dead and will get new widgets this year: https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/ https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/ My personal opinion of QML is also contradictional: QML on the desktop to me just feels like a glorified Electron, resizing windows is choppy, controls feel slightly "off", the "single page" approach just feels like it misses the platform's defining features (dialogs and multiple windows). Best example is KDE Discover. But I'd like to be proven wrong, I'd love to hear of QML desktop software that is genuinely high quality, but I haven't heard of any.
  - yellow_lead 8y ago
    As someone who recently worked with QML a lot, resizing is definitely a pain point. I have yet to see a great pattern for handling this, as there's definitely no one-size-fits-all within QML. For multiple pages, you can create multiple Windows / ApplicationWindows for one app. It definitely could have more support though - as for now you have to control these via C++ Qt code.
  - pfranz 8y ago
    Maybe they've done an about face? I was at a Qt panel a few years ago and they described QtWidgets as "feature complete" (i.e. not deprecated, but no longer developed). I'm not sure they knew their audience very well. This was a computer graphics conference, which has a lot of Python2 deeply integrated to this day (Python3 is a 2020 goal!). Most of the Qt written is simple windows where people type in values and move sliders. They seemed very surprised when nobody cared or had even tried QML. I gather QML was a push for mobile (which is in line with your criticisms) where QtWidgets wouldn't work at all. It happens to coincide with Electron bringing the mobile UI and web platform back to the desktop. Funny thing, a lot of the 3d apps themselves (Nuke, Maya, Houdini) have very custom UIs and have all ported to Qt. But this transitioned happened just before Qt5 so I'm pretty sure it's all heavily modified QtWidgets where QML might have been simpler to implement. However, any performance issues or drawing glitches might have been a dealbreaker. That's so important that these companies actually grouped together and forked Qt 5.6.1[1] with their own backported bug fixes and critical changes. Thankfully they've been working with The Qt Company to integrate them into mainline. [1] https://github.com/autodesk-forks/qtbase/tree/adsk-contrib/vfx/5.6.1 https://github.com/autodesk-forks/qtbase/tree/adsk-contrib/v...
    - toyg 8y ago
      > a push for mobile [...] where QtWidgets wouldn’t work at all Er, they actually worked fine on Maemo/Meego. I think even Android was supported at some point. But it has never been “cool”, and Nokia were desperate for getting cool. QML was an attempt at doing what Electron has done, but starting from the other end (i.e. desktop -> web, rather than the other way around). It was aimed squarely at “cool web people” trying to build desktop and mobile apps. I believe it was also supposed to be married with some integrated cloud service (where rendering a QML-based interface in-browser was obviously going to be much easier than reimplementing QtWidgets), but I had no interest in that sort of thing at the time, and I don’t know the current situation.
- quoyz 8y ago
  Time to join the future and rewrite the huge application I work on? I sure hope not.
- happyweasel 8y ago
  QML is a solution for a specific use case, it's not "the" future. QML also misses out on its widget set. It's too limited. There need to be a lot more widgets that work out of the box. Also excessive styling of elements seems to be needed. That's exactly something a developer can't do. Nice looking QWidgets were and are a simple way to empower a developer to create a useable UX quickly. Also there should be a C++-only API for creating Qt Quick widgets. It might be a good idea to leverage the c++ knowledge of your userbase, if your core userbase are c++ developers.
  - shaan7 8y ago
    > Also excessive styling of elements seems to be needed Um, not really. The inbuilt Universal style looks pretty good by default.
DiseasedBadger 8y ago
This (and WebEngine) is why we switched to Gtk. I'm sure it's a nice book, though.
- MarvelousWololo 8y ago
  Could you elaborate here please? I'm trying to learn qt at the moment.
  - toyg 8y ago
    I believe he means that he switched to GTK because Qt is moving away from traditional desktop widgets (in favour of QML / QtQuick) and he didn’t want to go that way.
    - MarvelousWololo 8y ago
      Hm that's a bummer. It sounds like it's taking the Electron path then? Because that's exactly what I was trying to avoid.
      - marcoms 8y ago
        The code is also compiled to native code, but it's written declaratively. It's not for everyone, but it's not the same as Electron. Even still you have the option to use the traditional imperative API.
  - fernly 8y ago
    I'm sure one cause is that QtWebEngine is a steaming garbage fire, with a far more limited API than the old WebKit based system, and many more bugs (not that the Qt4 WebKit support was a shining example) -- especially if you attempt to "deploy" (package) an app using it on MacOS.
- flukus 8y ago
  Gtk is also increasingly focusing on horrible xml UI's and treating the code API as a second class citizen, at least in documentation.
toyg 8y ago
The url and logo say “qmlbook”, so I guess it was originally meant to focus on QML only.
- fxfan 8y ago
  What else adds with qml to make Qt?
  - simonh 8y ago
    Mainly the QWidgets API interface inherited from Qt4, which is a traditional API calling interface.
  - toyg 8y ago
    Everything that was in Qt before Qt4, when QML was introduced :) Basically all the classic QtWidgets and the underneath desktop services.
quietbritishjim 8y ago
Indeed. I was bemused by the first sentence in the section explaining the architecture of Qt: > Qt Quick is the umbrella term for the user interface technology used in Qt 5. It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.

You mean QML? It's weird to see all of the C++ API reduced to a chapter. I've used Qt for years and QWidgets from C++ is all I've used.

by sjvpv 8y ago

You mean QML? It's weird to see all of the C++ API reduced to a chapter. I've used Qt for years and QWidgets from C++ is all I've used.

hellofunk 8y ago

QWidgets are not under active development, and the future is QML. QWidgets will likely only receive maintenance fixes going forward. Time to join the future!

781 8y ago
QML is just a teaser. Once you taste it you'll want the real thing and you'll move to Electron.
- discreteevent 8y ago
  I had the opposite experience. Each to their own.
- justinclift 8y ago
  The browser-application-pretending-to-be-a-desktop-application things I've seen don't handle multiple windows correctly, and most of them have problems with multi-key custom keyboard+mouse actions. :( Does Electron handle those scenarios well?
Longhanks 8y ago
According to the 2019 roadmap, QWidgets is very much not dead and will get new widgets this year: https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/ https://blog.qt.io/blog/2019/02/22/qt-roadmap-2019/ My personal opinion of QML is also contradictional: QML on the desktop to me just feels like a glorified Electron, resizing windows is choppy, controls feel slightly "off", the "single page" approach just feels like it misses the platform's defining features (dialogs and multiple windows). Best example is KDE Discover. But I'd like to be proven wrong, I'd love to hear of QML desktop software that is genuinely high quality, but I haven't heard of any.
- yellow_lead 8y ago
  As someone who recently worked with QML a lot, resizing is definitely a pain point. I have yet to see a great pattern for handling this, as there's definitely no one-size-fits-all within QML. For multiple pages, you can create multiple Windows / ApplicationWindows for one app. It definitely could have more support though - as for now you have to control these via C++ Qt code.
- pfranz 8y ago
  Maybe they've done an about face? I was at a Qt panel a few years ago and they described QtWidgets as "feature complete" (i.e. not deprecated, but no longer developed). I'm not sure they knew their audience very well. This was a computer graphics conference, which has a lot of Python2 deeply integrated to this day (Python3 is a 2020 goal!). Most of the Qt written is simple windows where people type in values and move sliders. They seemed very surprised when nobody cared or had even tried QML. I gather QML was a push for mobile (which is in line with your criticisms) where QtWidgets wouldn't work at all. It happens to coincide with Electron bringing the mobile UI and web platform back to the desktop. Funny thing, a lot of the 3d apps themselves (Nuke, Maya, Houdini) have very custom UIs and have all ported to Qt. But this transitioned happened just before Qt5 so I'm pretty sure it's all heavily modified QtWidgets where QML might have been simpler to implement. However, any performance issues or drawing glitches might have been a dealbreaker. That's so important that these companies actually grouped together and forked Qt 5.6.1[1] with their own backported bug fixes and critical changes. Thankfully they've been working with The Qt Company to integrate them into mainline. [1] https://github.com/autodesk-forks/qtbase/tree/adsk-contrib/vfx/5.6.1 https://github.com/autodesk-forks/qtbase/tree/adsk-contrib/v...
  - toyg 8y ago
    > a push for mobile [...] where QtWidgets wouldn’t work at all Er, they actually worked fine on Maemo/Meego. I think even Android was supported at some point. But it has never been “cool”, and Nokia were desperate for getting cool. QML was an attempt at doing what Electron has done, but starting from the other end (i.e. desktop -> web, rather than the other way around). It was aimed squarely at “cool web people” trying to build desktop and mobile apps. I believe it was also supposed to be married with some integrated cloud service (where rendering a QML-based interface in-browser was obviously going to be much easier than reimplementing QtWidgets), but I had no interest in that sort of thing at the time, and I don’t know the current situation.
quoyz 8y ago
Time to join the future and rewrite the huge application I work on? I sure hope not.
happyweasel 8y ago
QML is a solution for a specific use case, it's not "the" future. QML also misses out on its widget set. It's too limited. There need to be a lot more widgets that work out of the box. Also excessive styling of elements seems to be needed. That's exactly something a developer can't do. Nice looking QWidgets were and are a simple way to empower a developer to create a useable UX quickly. Also there should be a C++-only API for creating Qt Quick widgets. It might be a good idea to leverage the c++ knowledge of your userbase, if your core userbase are c++ developers.
- shaan7 8y ago
  > Also excessive styling of elements seems to be needed Um, not really. The inbuilt Universal style looks pretty good by default.

DiseasedBadger 8y ago

This (and WebEngine) is why we switched to Gtk. I'm sure it's a nice book, though.

MarvelousWololo 8y ago
Could you elaborate here please? I'm trying to learn qt at the moment.
- toyg 8y ago
  I believe he means that he switched to GTK because Qt is moving away from traditional desktop widgets (in favour of QML / QtQuick) and he didn’t want to go that way.
  - MarvelousWololo 8y ago
    Hm that's a bummer. It sounds like it's taking the Electron path then? Because that's exactly what I was trying to avoid.
    - marcoms 8y ago
      The code is also compiled to native code, but it's written declaratively. It's not for everyone, but it's not the same as Electron. Even still you have the option to use the traditional imperative API.
- fernly 8y ago
  I'm sure one cause is that QtWebEngine is a steaming garbage fire, with a far more limited API than the old WebKit based system, and many more bugs (not that the Qt4 WebKit support was a shining example) -- especially if you attempt to "deploy" (package) an app using it on MacOS.
flukus 8y ago
Gtk is also increasingly focusing on horrible xml UI's and treating the code API as a second class citizen, at least in documentation.

toyg 8y ago

The url and logo say “qmlbook”, so I guess it was originally meant to focus on QML only.

fxfan 8y ago
What else adds with qml to make Qt?
- simonh 8y ago
  Mainly the QWidgets API interface inherited from Qt4, which is a traditional API calling interface.
- toyg 8y ago
  Everything that was in Qt before Qt4, when QML was introduced :) Basically all the classic QtWidgets and the underneath desktop services.

quietbritishjim 8y ago

Indeed. I was bemused by the first sentence in the section explaining the architecture of Qt: > Qt Quick is the umbrella term for the user interface technology used in Qt 5. It is not "the" user interface technology in Qt, but one of them. This is a very confusing way to start a book that is supposed to be an introduction to Qt.