4 ms·
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 de
by 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.
- viraptor 8y ago> Er, they actually worked fine on Maemo/Meego. Maemo was basically a full Linux though. It was closer to desktop squeezed into a mobile screen than a mobile platform, so lots of things could be compiled and "just work".
- toyg 8y agoAt the time, Nokia had even ported Qt to Symbian, which is a much more limited platform than iOs or Android. I don’t think there is any real impediment to using QtWidgets on mobile platforms. Edit: to clarify, I mean the original Qt C++ toolkit, not the Python bindings (pyqt/pyside); the bindings only ever worked on Maemo, if i remember correctly.
- pjmlp 8y agoKind of. First they had to create PIPS, a POSIX environment for Symbian, because Symbian wasn't POSIX and the native language was a C++ dialect known as just Symbian C++. Secondly, the Qt based apps weren't pure Qt, you needed to have a couple of #ifdefs sprinkled around, calling Symbian APIs directly, even for a plain hello world.
- slavik81 8y agoIf you've ever tried to do fancy animations in C++ using QSceneView, it's obvious why they created QML. It is painful to manually maintain all the relationships and transient states needed for an interactive animated UI. QML makes that simple and easy. My only real problem with QML is that things can get really hairy really fast. QML does a great job of abstracting over it, but the complexity is all still there underneath. When something goes wrong, you end up debugging a tangeled mess of implicit behaviours, many of which were probably unintentional and unnoticed by anyone (including the original author that created them).
- flukus 8y ago> Er, they actually worked fine on Maemo/Meego. Long before then and before Nokia even, back when smartphones were called PDA's, the iphone wasn't released and when maemo was GTK based, there was a QtWidgets based environment called qtopia (https://en.wikipedia.org/wiki/Qt_Extended https://en.wikipedia.org/wiki/Qt_Extended).
- pjmlp 8y agoRight now they are focused on IoT and car infotainment systems, as those are the customers willing to pay for Qt licenses. You can get the latest update on their Meeting C++ 2018 session. "Recent developments and future outlook of Qt" https://youtu.be/PqLkBtA7DQc https://youtu.be/PqLkBtA7DQc
- mroche 8y ago> This was a computer graphics conference, which has a lot of Python2 deeply integrated to this day (Python3 is a 2020 goal!). Were you at SIGGRAPH? One of these days I’m going to make it to the conference and attend a meeting on the Platform. I was a little disappointed that 3.6 got offset to a tech preview with 2020 as the goal, but it’ll be worth it if we can get everyone using mainline Qt 5.12 AND official 5.12 PySide (Qt for Python...). The future is bright for the VFX Platform! Just not with QML, Widgets are here to stay for these kinds of apps.
- pfranz 8y agoYep. The talk I had attended was specifically about Qt. Most of the VFX reference platform discussion happens on the mailing list before Siggraph since they try to present next year's platform at the conference giving companies enough time to implement them by the new calendar year. But it is really cool to have people sit in a room together and share the problems/solutions only a few people at every company have to deal with. Python3 has been a topic brought up for many years and pushed off for other things. I'm kind of surprised how much progress they've made in moving these companies forward and keeping them roughly in step.
- mroche 8y agoI remember the reaction on the list when Python 3 was initially added and set (before Qt 5.12 was added). Felt like a universal sigh of relief. Then the discussion about which minor version to choose (3.7 was due in a few months at the time), but the general consensus was “just get us on 3, doesn’t matter which” so 3.6 it is. My only concern right now is Autodesk potentially dragging their feet on this, which I really hope they don’t do. But they’ve also got a lot of other things on their plate. A bit grumpy that their M2019 release is still using Qt 5.6.1 even with their several month delay that went into 2019, but maybe they’ll do something radical and upgrade it through. I remember Wayne and others being happy about the push to GCC 6.3 and finally being able to use C++14.