On 01/04/2021 16:13, Roland Hughes wrote:
On 4/1/21 8:46 AM, Giuseppe D'Angelo wrote:On 01/04/2021 13:40, Roland Hughes wrote:We keep discussing the ability to upgrade Qt but not upgrade the rest of the OS. I understand that Qt is a central component of the UI, but it's no less critical than a lot of other components that you may need to upgrade in order to deal with circumstances changing.What you are describing is __exactly__ why companies buy commercial licenses and pay for support contracts. They pay to have their environment supported and not be told that they have to replace their environment.The terms of the Qt support with a commercial entity (being it TQC or anyone else) have nothing to do with the Qt project decisions.Yes, they do. Is QtC providing code to Qt project? Is it providing hosting and distribution services for the OpenSource code? Is it providing any other financial support? When the answer to any of these is yes, then what they need has a lot to do with your decisions. When they need to support a platform for 15+ years and you rip it out after 6-7 _that_ is a real problem.
Does TQC provide hosting and other technological services for the Qt project? Yes, they do (thanks TQC!).
Does TQC provide the majority of code in the Qt project, and employ the biggest work force, therefore having a significant say in the Qt Project decisions? Yes.
Does TQC also provide commercial support contracts? Yes.(Is there a conflict of intents here because of the massive support to the Qt Project? I can't see how -- if anything, one could say that the commercial decisions may drive the decisions in the Qt Project, certainly NOT that the Qt Project has the power to "sabotage" the commercial decisions!)
But the terms of your commercial Qt support with TQC (or with anyone else for that matter) don't change depending on the Qt Project decisions. (And even if they did, then you've got nothing to complain about -- you _signed_ for that.) If your contract with TQC says that you have the right of getting 15+ years of support for some given Qt versions on some given platforms, then you get those, or you go to court. This has nothing to do with what the Qt Project decides to do in the meanwhile, including dropping those platforms after 6-7 years.
And, by the way, we're describing scenarios where the environment*has* changed: new hardware, new platforms, new toolchains. You're negating the premise, and thus the argument is a fallacy.No, your argument is the fallacy (which is not unusual.) They replaced a *monitor* with another computer monitor that the platform obviously supported. That's it. The video card obviously supported 4K as did the video driver. If the *environment* maxed out at 1920xwhatever Scott wouldn't have been screwed. He and his company got screwed because the high DPI support with the Qt they have was not good. Between "good enough" and what they currently have his platform got dropped. The platform already supported all of this. The Qt code did not.
The combination of monitor+Qt is by definition part of the environment (as far as the end-user application is concerned). Changing a monitor is changing the environment. If the definition of "supported" is "I connect it and it runs at 4K", then of course it's supported: you get the _native_ 4K from your Qt application, and no hidpi scaling.
But wait, don't your practices tell you that you should've run a risk analysis, filed in the holy 29 documents (all named with fancy acronyms, I'm sure), get an independent certification and applied the new cover sheet on your TPS reports (didn't you get the memo?) before approving the purchase of a new monitor model on a life-critical workstation?
(In all seriousness, of course I'm unhappy as the next person about the status of hidpi and Qt, and not too happy that one needs 5.15 for getting the bugfixes, which in turn has higher platform requirements. But this has nothing to do with someone having a commercial contract for pre-5.15 and thus with the power to get their commercial partner to backport those bugfixes or improvements.)
-- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
