[Interest] the path forward - that 7 year thing - was, , willy-nilly

[Giuseppe D'Angelo]

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.dangelo at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20210401/864b33ff/attachment.bin>