[Interest] QML Image sourceSize bug (?)

[Alexander Dyagilev]

I have PNG image of 256x256 size.

I'm trying to show it on 25x25 size using this code:

Image{

width:25

height:25

fillMode:Image.PreserveAspectFit

horizontalAlignment:Image.AlignHCenter

verticalAlignment:Image.AlignVCenter

source:preview.url

}

I'm getting this:

If I add sourceSize so the code becomes this:

Image{

width:25

height:25

sourceSize.height:25

sourceSize.width:25

fillMode:Image.PreserveAspectFit

horizontalAlignment:Image.AlignHCenter

verticalAlignment:Image.AlignVCenter

source:preview.url

}

I'm getting this:

Looks better. Why is it so?

OS: Windows 10. Screen.devicePixelRatio is 1.0.

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QML Image size vs sourceSize strange things

[Alexander Dyagilev]

This all is not about my question in any matter. I do not care about SVG 
at all. And SVG are not used in this example.


Please learn to read question before answering

On 3/23/2021 4:16 PM, Jérôme Godbout wrote:
Do you really need to same memory by reducing the source size? I think 
you should left the source size alone and sample the image from the 
full source. Source size for SVG doesn’t make any sense, it’s 
vectoriel, doesn’t have any size, it can scale to any dimension. When 
playing with the image size (not the source) it will sample the source 
for each pixel, not sure about the algorithm but you might need an 
higher source resolution to get a proper image without artifact. I 
would at least take the Screen.devicePixelRatio into the source size 
into account and even add a x2 to ensure proper sampling, but I don’t 
see any real advantage to play with the source size unless you really 
are consuming way too much memory.


This might slow you down if the same image is using different sourceSize:

Note: /Changing this property dynamically causes the image source to 
be reloaded, potentially even from the network, if it is not in the 
disk cache./

/
/

On Mar 23, 2021, at 3:31 AM, Alexander Dyagilev > wrote:


Hello,

We had a strange problem with blurred images under Retina displays. 
Left part of the image - before, right one - after the fix.




Our QML code was using with to show images:

Image{
anchors.verticalCenter:parent.verticalCenter
sourceSize.width:25
sourceSize.height:25
source:preview.url
}

I've tried to multiply sourceSize by Screen.devicePixelRatio - images 
became bigger so they did not fit their places.


Then I've replaced sourceSize.width with just width and the same for 
height. And it works fine now.


My questions is:

1) Is it required to multiply sourceSize by devicePixelRatio? Or is 
it managed automatically? It seems that it is managed automatically 
for PNG and NOT managed for SVG.


2) If it is already managed automatically for PNG (these images 
preview.url are PNGs) then why was it blurred? The original PNG image 
is of size 64x64 pixels under Retina displays.


___
Interest mailing list
Interest@qt-project.org 
https://lists.qt-project.org/listinfo/interest


Jerome Godbout
Software/Firmare Lead Amotus

C: (581) 777-0050
O: (418) 800-1073 ext.: 114
godbo...@amotus.ca 



dimonoff.com   | amotus.ca 

We have moved!
1015 Avenue Wilfrid-Pelletier, Québec, QC G1W 0C4, 4e étage

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Hamish Moffatt]

On 27/3/21 11:47 am, Scott Bloom wrote:

Sorry for top posting...

But I disagree here.  Even for mac, Qt 5 is 9 years old, 4 lived 6 (4.0->4.8 
LTS initial release, 4.8 lived for 3 years)

Im not saying we go to a Qt Major version for every mac system style change.  
But if they produce a SDK where previous version is so different than the new 
one, that the same Qt code needs a #ifdef XXX version, so be it.

Yes, its more work.



It's a runtime issue on macOS too, not just development. Recent macOS 
won't run anything compiled with an SDK earlier than the 10.9 version 
(due to their notarization requirements), so you can't keep compiling 
with an ancient toolchain. I don't know if you can use Qt 5.0 with the 
10.9 SDK, but I doubt it because Apple is quite aggressive about API 
deprecation.


I still haven't seen any convincing argument on why you expect to use a 
brand new Qt with ancient compilers/OSs?



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Scott Bloom]

Sorry for top posting...

But I disagree here.  Even for mac, Qt 5 is 9 years old, 4 lived 6 (4.0->4.8 
LTS initial release, 4.8 lived for 3 years)

Im not saying we go to a Qt Major version for every mac system style change.  
But if they produce a SDK where previous version is so different than the new 
one, that the same Qt code needs a #ifdef XXX version, so be it.

Yes, its more work.

Scott

-Original Message-
From: Hamish Moffatt  
Sent: Friday, March 26, 2021 17:40
To: Scott Bloom ; interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly

On 27/3/21 11:23 am, Scott Bloom wrote:
> To be clear.  Roland and I are talking about very different issues.
>
> To me, Qt should continue to support OS's/Compilers for the life of a 
> Major version of Qt.  if it built on Qt 5.0 it should build on that 
> OS/Compiler in 5.15
>
> If Qt decides that modern C++ was more important in 5.13, and the 
> compilers available on an OS/Compiler are no longer compiling Qt, then 
> frankly, its time to move to Qt 6
>
> There are many open source tool sets, that have parallel paths for a certain 
> time.  Qt 4 is a good example. The late stage Qt4 was still being supported 
> and new patch versions being put out as Qt 5 was rolling out.
>
> I do NOT expect to start a project in Qt3 on CentOS 3/4 (or whatever 
> it was) to be able to trivially rebuilt in Qt 4, or 5 when I move to 
> CentOS 7
>
> But If Im still using Qt 5.9 LTS, and decide to move to Qt 5.15 
> (skipping 12), I don’t expect my OSes to no longer be supported.  If 
> there was functionality being added to 13 that made a version of a 
> compiler/OS no longer valid to target? Make that functionality/code 
> for Qt 6


I'm not sure what you're asking is even possible on macOS. They churn the 
compiler and the SDK so quickly compared to the 8 year development life of Qt 5.

I would ideally like Qt to support deployment on macOS versions slightly older 
than they do. Not all the way back to what was supported in 5.0 though.

I don't see any compelling reason to be compiling with the latest Qt on ancient 
compilers/OSs though.


Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Hamish Moffatt]

On 27/3/21 11:23 am, Scott Bloom wrote:

To be clear.  Roland and I are talking about very different issues.

To me, Qt should continue to support OS's/Compilers for the life of a Major 
version of Qt.  if it built on Qt 5.0 it should build on that OS/Compiler in 
5.15

If Qt decides that modern C++ was more important in 5.13, and the compilers 
available on an OS/Compiler are no longer compiling Qt, then frankly, its time 
to move to Qt 6

There are many open source tool sets, that have parallel paths for a certain 
time.  Qt 4 is a good example. The late stage Qt4 was still being supported and 
new patch versions being put out as Qt 5 was rolling out.

I do NOT expect to start a project in Qt3 on CentOS 3/4 (or whatever it was) to 
be able to trivially rebuilt in Qt 4, or 5 when I move to CentOS 7

But If Im still using Qt 5.9 LTS, and decide to move to Qt 5.15 (skipping 12), 
I don’t expect my OSes to no longer be supported.  If there was functionality 
being added to 13 that made a version of a compiler/OS no longer valid to 
target? Make that functionality/code for Qt 6



I'm not sure what you're asking is even possible on macOS. They churn 
the compiler and the SDK so quickly compared to the 8 year development 
life of Qt 5.


I would ideally like Qt to support deployment on macOS versions slightly 
older than they do. Not all the way back to what was supported in 5.0 
though.


I don't see any compelling reason to be compiling with the latest Qt on 
ancient compilers/OSs though.



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Scott Bloom]

Forgot to mention this.

I do not expect something that built against Qt3/4/5 to build under Qt4/5/6 on 
the same OS/Compiler.

If Im changing OS, or compiler.  I hope to find a Qt that works on the new 
combo, (that’s rarely ever been an issue) but, my old version of Qt? if the 
major version is different, no I have no expectation.

My view, I would have made Qt 5.13 (or 14) "Qt 6.0" since there were many 
compiler versions dropped on that version  Then I would have ZERO concerns 
about moving to the latest and greatest Qt 5.x knowing my customers OSes would 
be fully supported.

If there is functionality fixes that the Qt team decides needs to be put into 
Qt 5.x, then they may have to code them twice, one using the 5.x and once using 
6.x code standards.  This is what Scintilla does between 2.x and 3.x (a much 
smaller project of course).

Scott

-Original Message-
From: Interest  On Behalf Of Scott Bloom
Sent: Friday, March 26, 2021 17:24
To: Hamish Moffatt ; interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly

To be clear.  Roland and I are talking about very different issues.

To me, Qt should continue to support OS's/Compilers for the life of a Major 
version of Qt.  if it built on Qt 5.0 it should build on that OS/Compiler in 
5.15

If Qt decides that modern C++ was more important in 5.13, and the compilers 
available on an OS/Compiler are no longer compiling Qt, then frankly, its time 
to move to Qt 6

There are many open source tool sets, that have parallel paths for a certain 
time.  Qt 4 is a good example. The late stage Qt4 was still being supported and 
new patch versions being put out as Qt 5 was rolling out.

I do NOT expect to start a project in Qt3 on CentOS 3/4 (or whatever it was) to 
be able to trivially rebuilt in Qt 4, or 5 when I move to CentOS 7

But If Im still using Qt 5.9 LTS, and decide to move to Qt 5.15 (skipping 12), 
I don’t expect my OSes to no longer be supported.  If there was functionality 
being added to 13 that made a version of a compiler/OS no longer valid to 
target? Make that functionality/code for Qt 6

Scott

-Original Message-
From: Interest  On Behalf Of Hamish Moffatt
Sent: Thursday, March 25, 2021 22:06
To: interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly

On 26/3/21 6:38 am, Roland Hughes wrote:
> According to the FDA fact sheet.
>
> https://www.fda.gov/about-fda/fda-basics/fact-sheet-fda-glance
>
> There are currently 25,864 registered FDA medical device facilities. 
> Not one of them can change a single approved process without going 
> through the FDA approval process for said change. That is __NOT__ a 
> sprint nor is it cheap. Within the past 18 months a drug manufacturer 
> in high priced California put out a cattle call for a PDP 11/44 (might 
> have been 24) system manager. Those machines were last made around 
> 1978. There is a group of them still making necessary drugs in California.
>
> Once something is in place it stays there because it is incredibly 
> expensive to replace.
>
>> Qt's horizon is about 7 years.
> That's 8 years too short. 
>> Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0.
>> Once you're in the 5.x series, port to 5.15 and fix the warnings. 
>> Once you're clean in a working build, port to Qt 6.
>
> There is no one who went to a good school for their IT degree where 
> they made the person take Cost Accounting ever going to utter that as 
> a valid path forward.
>
> There is no MBA, even from a shit school like Keller, that is going to 
> sign off on such a project.
>

I really don't understand your arguments Roland. You say you need Qt support 
for 15 years, but you can't actually change one bit of your software without 
FDA approval, so presumably this means you aren't upgrading Qt anyway. Then 
after 15 years you want to work on a new model of the device, starting with 
your existing code, and you expect it to compile with the latest Qt unchanged?


Someone else was talking about support for RHEL 6. Why do you expect to use the 
latest Qt with an ancient OS? Is it reasonable to expect to use new Qt with an 
ancient OS?

I see that the latest Microsoft Visual C++ compiler toolset (v142) doesn't 
support building for Windows XP. You can still use an older compiler. That 
seems like a reasonable compromise.



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Scott Bloom]

From the Qt blog post https://www.qt.io/blog/qt-offering-changes-2020

"These changes will not have any effect on existing commercial licensing or 
services agreements."

Now, it doesn’t talk about the notion that if you built and produced your code 
against a commercial license, it has to remain in force for you to be 
considered licensed.

As you say Roland, I have no idea how that could be possible for an existing 
contract, but going forward its not an uncommon licensing strategy.

Scott
-Original Message-
From: Interest  On Behalf Of Roland Hughes
Sent: Friday, March 26, 2021 14:33
To: interest@qt-project.org; jh...@gmx.com
Subject: Re: [Interest] the path forward - that 7 year thing - was, willy-nilly


On 3/26/21 1:39 PM, Jason H wrote:
> Thiago, apparently, even with a commercial license, we no longer have 
> rights to use whatever versions were current when we had the license. 
> Previously, we could use it in perpetuity. This is probably a deal 
> breaker at my new organization. It is my understanding that after our 
> software development is done, we have to maintain commercial licenses 
> even when we are not_developing_  software in Qt. I think the previous 
> perpetuity licensing was appropriate.

**Seriously**

They are trying to end a 5.x perpetuity license that was already bought and 
paid for? Nah. Can't be. I know a customer that paid north of $600K for such a 
license and the device isn't yet out the door. They happen to have a lot of 
lawyers too. I can't believe they would take that lying down.

What I "thought" was said was you could no longer obtain such a license. 
I don't agree with that, but that policy doesn't place QtC in legal jepordy 
because the license change only impacts new product.

I'm not a lawyer, but if you bought a license, they (QtC) can't just 
arbitrarily end said license. Companies will be suing for return of license 
fees and for damages.

--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Scott Bloom]

To be clear.  Roland and I are talking about very different issues.

To me, Qt should continue to support OS's/Compilers for the life of a Major 
version of Qt.  if it built on Qt 5.0 it should build on that OS/Compiler in 
5.15

If Qt decides that modern C++ was more important in 5.13, and the compilers 
available on an OS/Compiler are no longer compiling Qt, then frankly, its time 
to move to Qt 6

There are many open source tool sets, that have parallel paths for a certain 
time.  Qt 4 is a good example. The late stage Qt4 was still being supported and 
new patch versions being put out as Qt 5 was rolling out.

I do NOT expect to start a project in Qt3 on CentOS 3/4 (or whatever it was) to 
be able to trivially rebuilt in Qt 4, or 5 when I move to CentOS 7

But If Im still using Qt 5.9 LTS, and decide to move to Qt 5.15 (skipping 12), 
I don’t expect my OSes to no longer be supported.  If there was functionality 
being added to 13 that made a version of a compiler/OS no longer valid to 
target? Make that functionality/code for Qt 6

Scott

-Original Message-
From: Interest  On Behalf Of Hamish Moffatt
Sent: Thursday, March 25, 2021 22:06
To: interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly

On 26/3/21 6:38 am, Roland Hughes wrote:
> According to the FDA fact sheet.
>
> https://www.fda.gov/about-fda/fda-basics/fact-sheet-fda-glance
>
> There are currently 25,864 registered FDA medical device facilities. 
> Not one of them can change a single approved process without going 
> through the FDA approval process for said change. That is __NOT__ a 
> sprint nor is it cheap. Within the past 18 months a drug manufacturer 
> in high priced California put out a cattle call for a PDP 11/44 (might 
> have been 24) system manager. Those machines were last made around 
> 1978. There is a group of them still making necessary drugs in California.
>
> Once something is in place it stays there because it is incredibly 
> expensive to replace.
>
>> Qt's horizon is about 7 years.
> That's 8 years too short. 
>> Anything coded to Qt 3.x needs to ported first to 4.8, before going to 5.0.
>> Once you're in the 5.x series, port to 5.15 and fix the warnings. 
>> Once you're clean in a working build, port to Qt 6.
>
> There is no one who went to a good school for their IT degree where 
> they made the person take Cost Accounting ever going to utter that as 
> a valid path forward.
>
> There is no MBA, even from a shit school like Keller, that is going to 
> sign off on such a project.
>

I really don't understand your arguments Roland. You say you need Qt support 
for 15 years, but you can't actually change one bit of your software without 
FDA approval, so presumably this means you aren't upgrading Qt anyway. Then 
after 15 years you want to work on a new model of the device, starting with 
your existing code, and you expect it to compile with the latest Qt unchanged?


Someone else was talking about support for RHEL 6. Why do you expect to use the 
latest Qt with an ancient OS? Is it reasonable to expect to use new Qt with an 
ancient OS?

I see that the latest Microsoft Visual C++ compiler toolset (v142) doesn't 
support building for Windows XP. You can still use an older compiler. That 
seems like a reasonable compromise.



Hamish

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Roland Hughes]

On 3/26/21 1:39 PM, Jason H wrote:

Thiago, apparently, even with a commercial license, we no longer have rights
to use whatever versions were current when we had the license. Previously, we 
could use
it in perpetuity. This is probably a deal breaker at my new organization. It is 
my
understanding that after our software development is done, we have to maintain
commercial licenses even when we are not_developing_  software in Qt. I think 
the previous
perpetuity licensing was appropriate.


**Seriously**

They are trying to end a 5.x perpetuity license that was already bought 
and paid for? Nah. Can't be. I know a customer that paid north of $600K 
for such a license and the device isn't yet out the door. They happen to 
have a lot of lawyers too. I can't believe they would take that lying down.


What I "thought" was said was you could no longer obtain such a license. 
I don't agree with that, but that policy doesn't place QtC in legal 
jepordy because the license change only impacts new product.


I'm not a lawyer, but if you bought a license, they (QtC) can't just 
arbitrarily end said license. Companies will be suing for return of 
license fees and for damages.


--
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Roland Hughes]

On 3/26/21 1:39 PM, Michael Jackson wrote:

 I'll start off by acknowledging your points, but we will just agree to 
disagree. I acknowledge that you have a*lot*  of years making/maintaining 
software for medical devices. But I'm with Hamish on this. I don't understand.

What you are saying is that Qt was designed "perfectly" from day one with no 
extra API, not one bad API implementation and no cruft. Qt should never be updated to run 
on modern compilers against modern C++ specifications. Updated to run on modern operating 
systems. Qt should not explore adding APIs/Toolkits to the Qt ecosystem to allow Qt to be 
used on the billions of devices that we use every day. Qt should just stick with its 
technology from 20 years ago. TQtC shouldn't go after paying customers in order to, you 
know, pay its developers. TQtC should rely solely on an industry that, by your own 
writings, have a 15 year horizon. Not much of a business case for that. (For the record, 
I don't particularly agree with TQtC current licensing or LTS strategy.)


No. Not what I'm saying at all. I have no idea how you got there from 
what I've said.


Stable API.  Nothing ever gets deleted until it has a direct or mostly 
replacement *within* the existing product.


When Qt chased these markets it knew what the lifetimes would be. Now it 
has abandoned them.



I also don't understand your argument that you want to update a medical device 
from 20 years ago with the latest and greatest toolkits. I can't imagine 
anything electronic from 20 years ago being able to actually load and run 
anything like Qt? How is the hardware even powerful enough to do this? You 
can't convince me that the medical hardware device manufacturers were thinking 
15 years into the future for the next upgrade, 15 years ago.
The surgical robots being sold today will require 20 year support 
lifespans. Many of the devices sold over the past decade were sold with 
a minimum 10 year support and maintenance requirement. The development 
effort on these devices runs into the millions. You can't make a bet 
like that and find out a year later the supplier flew off to the Cayman 
Islands with Ted Cruz and your money.

50 Year Old equipment. You make the case even more for TQtC to pursue customers 
with a much shorter timeline. If TQtC concentrated on markets with 20-50 year 
timelines for updates how much revenue do you think they would make? Enough to 
sustain Qt development in any real capacity? Doubtful.


Okay. There's an education situation here.

I've never worked for a one-trick-pony medical device company. For 
certain there are the grant/research funded things coming out of college 
labs. That Phd. student doesn't take it to production. A Baxter, 
Hill-Rom, GE, etc. type player will be who said thing gets sold to. They 
will take it through FDA approval and to full production. Usually they 
end up hiring the person or small college team that created it.


Baxter (and I imagine all the rest) actually invest in many tiny startup 
medical device companies if there is a good idea that has already had 
some fundamental work. They invest with the intent of consuming some/all 
of it when it is obvious the thing will work. Here, this might help.


https://www.gehealthcare.com/products/accessories-and-supplies/clinical-accessories-and-supplies

Click on Products & Services and then click Equipment and follow across. 
Those are just the devices GE puts out under its *own* brand. It owns 
whole or in part lots of other little companies putting out medical 
devices under their own brand. Hill-Rom is much the same from that 
perspective.


You are thinking in terms of the x86 world where there are oceans of 
one-trick-ponies. Companies like Install-Shield that had one big hit 
followed by some flame-outs. Last I heard they were still just a one 
product company. It's a cultural thing tied to that platform.


Here's reality in the medical device world.

Year one you get told to create a new patient monitor that looks like 
any of the ones in this list of images.


https://duckduckgo.com/?t=canonical=patient+monitor+image=images=images

It has a pump for blood pressure cuff, SP/O2, thermometer, and ability 
to record/display some patient info like weight and body mass. The UX 
team comes up with a style, fantastic graphics, even a custom font to 
support all of the supported languages. Management tells you what they 
are going to buy for a processor and RAM. They put a stake in the ground 
on battery life and recharge time, etc.


You work like dog for 6-8 months. Product goes off for FDA approval. The 
day __after__ everybody goes out for drinks management team tells 
hardware team to split into two groups.


Group 1: Design and build a new & improved hospital bed with built in 
scale so nursing homes don't have to get immobile people up to weigh 
them. (For those who don't know, they are required to record resident 
weight at least monthly. One of the dead give-aways 

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

[Michael Jackson]

Roland,
I'll start off by acknowledging your points, but we will just agree to 
disagree. I acknowledge that you have a *lot* of years making/maintaining 
software for medical devices. But I'm with Hamish on this. I don't understand.

What you are saying is that Qt was designed "perfectly" from day one with no 
extra API, not one bad API implementation and no cruft. Qt should never be 
updated to run on modern compilers against modern C++ specifications. Updated 
to run on modern operating systems. Qt should not explore adding APIs/Toolkits 
to the Qt ecosystem to allow Qt to be used on the billions of devices that we 
use every day. Qt should just stick with its technology from 20 years ago. TQtC 
shouldn't go after paying customers in order to, you know, pay its developers. 
TQtC should rely solely on an industry that, by your own writings, have a 15 
year horizon. Not much of a business case for that. (For the record, I don't 
particularly agree with TQtC current licensing or LTS strategy.)

I also don't understand your argument that you want to update a medical device 
from 20 years ago with the latest and greatest toolkits. I can't imagine 
anything electronic from 20 years ago being able to actually load and run 
anything like Qt? How is the hardware even powerful enough to do this? You 
can't convince me that the medical hardware device manufacturers were thinking 
15 years into the future for the next upgrade, 15 years ago.

50 Year Old equipment. You make the case even more for TQtC to pursue customers 
with a much shorter timeline. If TQtC concentrated on markets with 20-50 year 
timelines for updates how much revenue do you think they would make? Enough to 
sustain Qt development in any real capacity? Doubtful.

Some of us like to create cross platform desktop applications that inspire our 
users to create the next cool thing. For that Qt is just about the only viable 
toolkit out there although others are coming on strong. We would like to see Qt 
keeping up with the latest C++ specs so we can use all the cool new APIs. Both 
our software development worlds are important to each of us. We are almost 
diametrically opposed in what we want from the same toolkit. Neither is 100% 
right and neither is 100% wrong. Only TQtC can decide where to put their 
resources so that they make enough revenue to continue the development of Qt.

I'm not going to comment on the Fortran thing. It isn't relevant to this 
conversation.

Again, this is *not* an endorsement of the current licensing issues with Qt 
5.15 and 6.0. I'm just enough put off to find something else after 15 years of 
using Qt.
--
Michael Jackson | Owner, President
  BlueQuartz Software
[e] mike.jack...@bluequartz.net
[w] www.bluequartz.net
 

On 3/26/21, 9:45 AM, "Interest on behalf of Roland Hughes" 
 
wrote:


On 3/26/21 6:00 AM, Hamish Moffatt wrote:
> I really don't understand your arguments Roland. You say you need Qt
> support for 15 years, but you can't actually change one bit of your
> software without FDA approval, so presumably this means you aren't
> upgrading Qt anyway. Then after 15 years you want to work on a new model
> of the device, starting with your existing code, and you expect it to
> compile with the latest Qt unchanged?

Stable API.

By definition a Stable API only has additions. In incredibly rare 
isolated cases things get deleted ___AFTER__ they have a direct or 
mostly direct replacement.

I was involved in a discussion a couple months ago with someone who just 
that morning cracked open 50 year old FORTRAN that compiled with the 
latest FORTRAN compiler just fine. The code had been running in 
production unchanged for 50 years. That's ordinary in the deep pockets 
world, not an exception, the rule.

> Someone else was talking about support for RHEL 6. Why do you expect to
> use the latest Qt with an ancient OS? Is it reasonable to expect to use
> new Qt with an ancient OS?

Qt actively pursued these markets and then abandoned them. Multi-million 
dollar investments (if I remember what Scott wrote correctly, a billion 
with a B dollar investment) on long term projects. Well, ordinary term 
for our worlds but beyond the Arc of Time for what Qt now pursues. These 
investments got made because the stuff was supposed to be supported for 
the duration.

Our worlds last longer than a gallon of milk and they were actively pursued.

>
> I see that the latest Microsoft Visual C++ compiler toolset (v142)
> doesn't support building for Windows XP. You can still use an older
> compiler. That seems like a reasonable compromise.
>
When you come from a short lived world, that would seem reasonable. We 
walk in worlds where stuff routinely runs 30-50 years. It's a requirement.

The gist of this thread seems to be, from Thiago and others, is that 
those who need Qt to be a viable 

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

[eric.fedosejevs]

The FitBit and its many fly-by-night knockoffs are a great example. Its “food 
plan” app will probably soon have privileged access to all of your kitchen 
appliances. And it can even be used to monitor when the supervisor at your 
local nuclear power plant goes on his daily constitutional.

 

From: Roland Hughes  
Sent: Friday, March 26, 2021 9:52 AM

 

Because even something like a FitBit, if it connects to the Internet, can be 
used as part of a swarm for an attack.

 

From: Roland Hughes  
Sent: Friday, March 26, 2021 9:52 AM
To: eric.fedosej...@gmail.com; interest@qt-project.org
Subject: Re: [Interest] the path forward - that 7 year thing - was, willy-nilly

 

 

On 3/26/21 9:23 AM, eric.fedosej...@gmail.com 
  wrote:

There are much worse possible outcomes than spoiled food. “App-controlled” 
smart ovens are now all the rage. Even if there are safety measures to prevent 
remotely burning down your house, what fraction of ovens in a community do you 
need to simultaneously preheat to bring down the entire electrical grid? 
Probably not too many. The grid is designed for small and continuous changes in 
demand, not large and coordinated changes due to an IoT attack. Once the grid 
is down, it can take a long time to bring back up due to a lack of investment 
in black start capacity.

 

https://www.welivesecurity.com/2018/09/06/madiot-home-appliances-power-grids/

 

Qt Co. is in for quite the surprise when new regulations are introduced and 
Agile development/subscription toolkit licensing are driven out of the IoT 
market. But is current management capable of looking that far ahead?

 

Agreed. I just didn't want to go too deep on the "why" said regulation is 
coming. Every country that currently has regulations on medical and SAFETY 
devices will impose regulation on the IoT market and it will be the same 
draconian (by some descriptions) stuff imposed on the human/animal life world. 
Why? Because even something like a FitBit, if it connects to the Internet, can 
be used as part of a swarm for an attack.

Thank God none of the nuclear power plants in America have any connection to 
the Internet. At least the control systems don't.

https://blog.ucsusa.org/edwin-lyman/6-things-to-know-about-the-2020-cyberattack-and-nuclear-power-plants

The electrical grid, however, is not so well protected.

I was in a 20-something floor apartment that weekend day when a Chicago power 
station detonated. Just a few blocks away from where I was at "they" actually 
talked someone into holding a fire hose and continuously spraying that power 
station to keep it from going up.

Power station may be the incorrect term. I didn't look up the proper name. Am 
to this day floored that someone could be talked into spraying water on 
electrical equipment with something like a Terawatt of power going through it.

 

-- 

Roland Hughes, President
Logikal Solutions
(630)-205-1593
 
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Extracting available imports from QML plugins for package dependencies

[Ulf Hermann]

Hi Fabian,

In general, you should bug your upstream to provide a qmltypes file for 
each module. They know best what types they want to expose in what 
version and under what URI. I do understand that upstream may be less 
than delighted, though ...


Modern QML applications generate their qmltypes files at build time via 
CONFIG += qmltypes. Those qmltypes files should be installed alongside 
the qmldir file. They contain information about URIs and versions. The 
qmldir file, in turn, should have a "typeinfo" entry that points to the 
qmltypes file.


If you have an old project that doesn't provide a qmltypes file, you can 
indeed run qmlplugindump to generate qmltypes from a given binary. 
Indeed you currently have to give it the latest version it's supposed to 
expose. It should also list any older versions in the "export" entries, 
though. However, qmlplugindump might have bugs. Technically, it's also 
deprecated. Yet, I would still accept the occasional bug fix, or a 
change that makes the version argument optional. This way it could list 
everything without requiring the maximum version to be known beforehand.


Finally, the lack of information about the maximum acceptable version is 
a deficiency of the qmltypes format. We should add an entry about it in 
the top level scope. It wouldn't be too hard to teach qmltyperegistrar 
or qmlplugindump how to generate that.


best regards,
Ulf
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Roland Hughes]

On 3/26/21 9:23 AM, eric.fedosej...@gmail.com wrote:


There are much worse possible outcomes than spoiled food. 
“App-controlled” smart ovens are now all the rage. Even if there are 
safety measures to prevent remotely burning down your house, what 
fraction of ovens in a community do you need to simultaneously preheat 
to bring down the entire electrical grid? Probably not too many. The 
grid is designed for small and continuous changes in demand, not large 
and coordinated changes due to an IoT attack. Once the grid is down, 
it can take a long time to bring back up due to a lack of investment 
in black start capacity.


https://www.welivesecurity.com/2018/09/06/madiot-home-appliances-power-grids/ 



Qt Co. is in for quite the surprise when new regulations are 
introduced and Agile development/subscription toolkit licensing are 
driven out of the IoT market. But is current management capable of 
looking that far ahead?




Agreed. I just didn't want to go too deep on the "why" said regulation 
is coming. Every country that currently has regulations on medical and 
SAFETY devices will impose regulation on the IoT market and it will be 
the same draconian (by some descriptions) stuff imposed on the 
human/animal life world. Why? Because even something like a FitBit, if 
it connects to the Internet, can be used as part of a swarm for an attack.


Thank God none of the nuclear power plants in America have any 
connection to the Internet. At least the control systems don't.


https://blog.ucsusa.org/edwin-lyman/6-things-to-know-about-the-2020-cyberattack-and-nuclear-power-plants

The electrical grid, however, is not so well protected.

I was in a 20-something floor apartment that weekend day when a Chicago 
power station detonated. Just a few blocks away from where I was at 
"they" actually talked someone into holding a fire hose and continuously 
spraying that power station to keep it from going up.


Power station may be the incorrect term. I didn't look up the proper 
name. Am to this day floored that someone could be talked into spraying 
water on electrical equipment with something like a Terawatt of power 
going through it.



--


Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[eric.fedosejevs]

There are much worse possible outcomes than spoiled food. “App-controlled” 
smart ovens are now all the rage. Even if there are safety measures to prevent 
remotely burning down your house, what fraction of ovens in a community do you 
need to simultaneously preheat to bring down the entire electrical grid? 
Probably not too many. The grid is designed for small and continuous changes in 
demand, not large and coordinated changes due to an IoT attack. Once the grid 
is down, it can take a long time to bring back up due to a lack of investment 
in black start capacity.

 

https://www.welivesecurity.com/2018/09/06/madiot-home-appliances-power-grids/

 

Qt Co. is in for quite the surprise when new regulations are introduced and 
Agile development/subscription toolkit licensing are driven out of the IoT 
market. But is current management capable of looking that far ahead?

 

From: Interest  On Behalf Of Roland Hughes
Sent: Friday, March 26, 2021 7:44 AM

 
The Wild Wild West days of IoT are coming to a hard close. It's not just the 
DDOS attacks. With connected refrigerators, hackers can turn the things off 
while people are at work (post pandemic) and spoil the majority of food in a 
city the size of Chicago, New York, LA, etc. If they choose to do it in every 
major city at once it leads to massive food insecurity.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Roland Hughes]

On 3/26/21 6:00 AM, Hamish Moffatt wrote:

I really don't understand your arguments Roland. You say you need Qt
support for 15 years, but you can't actually change one bit of your
software without FDA approval, so presumably this means you aren't
upgrading Qt anyway. Then after 15 years you want to work on a new model
of the device, starting with your existing code, and you expect it to
compile with the latest Qt unchanged?


Stable API.

By definition a Stable API only has additions. In incredibly rare 
isolated cases things get deleted ___AFTER__ they have a direct or 
mostly direct replacement.


I was involved in a discussion a couple months ago with someone who just 
that morning cracked open 50 year old FORTRAN that compiled with the 
latest FORTRAN compiler just fine. The code had been running in 
production unchanged for 50 years. That's ordinary in the deep pockets 
world, not an exception, the rule.



Someone else was talking about support for RHEL 6. Why do you expect to
use the latest Qt with an ancient OS? Is it reasonable to expect to use
new Qt with an ancient OS?


Qt actively pursued these markets and then abandoned them. Multi-million 
dollar investments (if I remember what Scott wrote correctly, a billion 
with a B dollar investment) on long term projects. Well, ordinary term 
for our worlds but beyond the Arc of Time for what Qt now pursues. These 
investments got made because the stuff was supposed to be supported for 
the duration.


Our worlds last longer than a gallon of milk and they were actively pursued.



I see that the latest Microsoft Visual C++ compiler toolset (v142)
doesn't support building for Windows XP. You can still use an older
compiler. That seems like a reasonable compromise.

When you come from a short lived world, that would seem reasonable. We 
walk in worlds where stuff routinely runs 30-50 years. It's a requirement.


The gist of this thread seems to be, from Thiago and others, is that 
those who need Qt to be a viable product with a stable API need to fork 
it into a completely separate project that doesn't delete anything 
without querying the installed base. You want to see how viable 
companies and products are managed.


===



Hi Roland,


We'll soon be making decisions about Synergy/DE product direction in a 
number of areas, as well as about potential new products, and we're very 
interested in your input. Please complete this brief survey to help us 
determine our priorities and future development direction.


Start Survey


Or use this link: https://survey.sogosurvey.com/k/QsQWSXRSsRWsSUXUSWVQTsP


SURVEY DEADLINE: Tuesday, March 30 (end of day)

Everyone who completes the survey will be entered into a raffle to win a 
$250 gift card.


Thank you for participating,
The Synergex Team

===

I haven't done squat with DIBOL in years. I did write Synergex a nice 
"how to use it on VMS" chapter some years ago that they are free to use 
however they want. Every time they are ready for major changes one of 
these things comes out. They understand that the care and feeding of the 
installed base is what keeps a roof over their head and food on their 
table. That once you pursue an industry and get it to invest in your 
product, you don't abandon it.


The mantra from the Qt project, and Digia for that matter, is "Sucks to 
be you!"


You want the Cliff Notes response?

Qt as a community and commercial product pursued the medical device and 
SAFETY industries because of their deep pockets. They pursued these 
industries knowing full well that, baring a product with adverse 
outcomes, 15 years would be the soonest redevelopment would happen.


From time to time we get hit with new industry regulations and have to 
tweak something. During those times we tend to update any libraries 
because we are going to have to bite the bullet on some level of 
approval anyway. We can successfully do this when we have a stable API. 
What you can't generally do is slip in a new OS.


Here is a real life real world example.

Most every medical device manufacturer that had touch screens on their 
devices had super secret field service screens on the device. When the 
devices had an external USB or other connection it was customized to 
have extra pins and those screens couldn't be accessed unless you had 
the "key" so to speak. In addition to the "key" you had to know the 
field service access code. Usually a 4-6 digit code. For devices that 
didn't have external ports you had to have the proper tool to crack up 
the case so you could install the field service card that had the port.


Most considered bifurcated security good enough. Everybody overlooked 
the fact that XYZ corporation's products all used 1709 as their access 
code and Harry Widgets medical devices all used 4591. Not just one 
model, all models.


In the Post 9/11 cyber security changes that started coming down the FDA 
decided that each customer should be able to set their own field service 
code and 

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

[Jason H]

> Sent: Thursday, March 25, 2021 at 9:41 PM
> From: "Thiago Macieira" 
> To: interest@qt-project.org
> Subject: Re: [Interest] the path forward - that 7 year thing - was willy-nilly
>
> On Thursday, 25 March 2021 12:38:56 PDT Roland Hughes wrote:
> > > Qt's horizon is about 7 years.
> >
> > That's 8 years too short.
>
> For this industry, sure. But it's not Qt's promise. The fact that some
> industries require a higher standard of support or coding practices or
> stability does not immediately mean that it must be done in all software.
>
> It doesn't make economical sense for Qt to provide support for 15 years. If
> you need Qt for that long, you should engage a consultancy that will sell you
> that contract, the same way that Red Hat sells support for RHEL 6 for 14 years
> total (2010-2024).


Thiago, apparently, even with a commercial license, we no longer have rights
to use whatever versions were current when we had the license. Previously, we 
could use
it in perpetuity. This is probably a deal breaker at my new organization. It is 
my
understanding that after our software development is done, we have to maintain
commercial licenses even when we are not _developing_ software in Qt. I think 
the previous
perpetuity licensing was appropriate.





___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

[Interest] Extracting available imports from QML plugins for package dependencies

[Fabian Vogt]

Hi,

I'm one of the Qt+KDE package maintainers for openSUSE. For making sure that
all shipped .qml files have their imports available, during package build we
generate a list of provided and required capabilities for packages including
.qml and qmldir files. Those are used by RPM and package management tools for
dependency resolution. In practice it looks like this:

qtgraphicaleffects 5.15 provides qt5qmlimport(QtGraphicalEffects.1) = 15
qtquickcontrols2 5.15 requires qt5qmlimport(QtGraphicalEffects.1) >= 12 

So simply because a .qml file in the qtquickcontrols2 package contains
"import QtGraphicalEffects 1.12", it automatically pulls in qtgraphicaleffects
in the right version.

[1] has a more in-depth explanation on how the capabilities are designed and
implemented.

Generating the list of required QML imports is easy: For each .qml file just
run qmlimportscanner and put it into a format which RPM understands. The
biggest hurdle here is to decide which Qt version a .qml file will be used with
during runtime, as this decides for instance whether qtquickcontrols2 from Qt 5
or Qt 6 is needed.

Finding out what a QML module provides is much harder. The task is basically:
Given a qmldir file, find out which import statements it can satisfy (including
version). This is pretty much the QML engine's import resolution in reverse.
For simple qmldir files which just reference components written in QML, the
information is directly available: For each major version, get the highest
minor version.

Once plugins are involved, it gets more complex. The version information is
now contained in code with arbitrary logic, so the only way to get to it is by
loading the plugin and executing the registration code. qmlplugindump works
like that, but it's unfortunately not suitable for this. It needs both the
URI and major.minor versions, but the task is to find out the available versions
in the first place.

Additionally, the information it dumps lacks some important aspects of
registration, like for instance the versions passed to qmlRegisterModule, which
can bump the maximum available minor version without registering a type for it.
This is for instance how qtquickcontrols2 5.14 achieves that it can be imported
as 5.14, even if no new features were added for that minor version bump.
Without being aware of such calls, the generated capability would only express
"qt5qmlimport(QtQuick.Controls.2) >= 13".

To get around the restrictions of qmlplugindump, I wrote a custom program [2]
which uses the private API (yuck) to load a plugin and get all available URIs
and versions. It also catches qmlRegisterModule manually.

Is there already a better way to do this? If not, could it maybe be added to
qmlplugindump?

This mechanism is used for package builds in openSUSE Tumbleweed for a few
months now and thus pretty much left the PoC phase. So I'd like to get at least
some parts of this upstream, if possible.

[1] Documentation of how the capabilities work:
https://build.opensuse.org/package/view_file/openSUSE:Factory/qml-autoreqprov/README?expand=1

[2] Current program used to dump available exports:
https://build.opensuse.org/package/view_file/openSUSE:Factory/qmlpluginexports/qmlpluginexports.cpp?expand=1

Cheers,
Fabian


___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

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

[Roland Hughes]

On 3/26/21 6:00 AM, Thiago Macieira wrote:

It doesn't make economical sense for Qt to provide support for 15 years. If
you need Qt for that long, you should engage a consultancy that will sell you
that contract, the same way that Red Hat sells support for RHEL 6 for 14 years
total (2010-2024).
What you are really saying is that industries needing actual stability 
need to fork Qt into a different product.



Anything coded to Qt 3.x needs to ported first to 4.8, before going to
5.0.
Once you're in the 5.x series, port to 5.15 and fix the warnings. Once
you're clean in a working build, port to Qt 6.

There is no one who went to a good school for their IT degree where they
made the person take Cost Accounting ever going to utter that as a valid
path forward.

There is no MBA, even from a shit school like Keller, that is going to
sign off on such a project.

That might be, but they may have a bigger cost instead when they need to port
to what is current at the time.


This is completely wrong. The patient monitor I worked on went through 
the full process reusing many things from previous patient monitor and 
weighed in around $1.2 - $1.4 million. Client said that is roughly what 
every iteration costs. Your path, going 3.x to 4.8 ($1.2 million); 4.8 
to 5.0 ($1.2 million); 5.0 to 5.15 ($1.2 million); 5.15 to 6.8 [roughly 
when it sounds like everything will actually be there] ($1.2 million) 
for a grand total of $4.8 million using the low number for what each 
iteration costs.


3.0 to an API compatible 6.x ($1.2 million) 3.0 to one of the 5.x 
versions (because 6 no ready) $1.8 million.  The 3.0 version to 
different framework $1.4 million. Rough estimates were already done.


Iteration never "saves money"


people when those releases were made and the warnings added?

Watching production systems continue to run and generate revenue or save
lives, sometimes both. Until management makes a decision to update,
there is nothing for them to do.

I call that shortsighted: failing to learn from innovation and predict future
changes. It saves money in the short term, as you readily state, no doubt.
You did read the part about the drug manufacturer looking for PDP 11 
system manager, correct? Last year of manufacture 1978. That _is_ short 
term for this industry.



That is spoken like someone who has always worked in the
x86-wanna-be-a-real-computer-when-I-grow-up hacking on the fly world. In
the regulated world, whether you ship a product or not doesn't matter.
The development process requires you create The Four Holy Documents up
front.. You have a full QA team with a formal and documented as executed
testing plan. Full formal code review with secretary and official form
filing. A full formal test by an authorized third party of the device
off the actual and formally certified production line. It can't be a
one-off or a "pilot" line. It has to be*the*  line that will produce
units for sale.

I've never doubted that what you're saying does happen, in some industries.

I'm saying that there are a lot of others where what you're saying does not
happen. Those generate far more money for the actors involved here.
Qt pursued the embedded systems market then went for the flash in the 
pan markets.


And if you look at my email address, you'll realise that "x86-wanna-be-a-real-
computer" is insulting.


It's reality. You may not like reality, but it is reality.

How 'bout that Itanium? Yeah baby!


Like I said, I can't help if feedback wasn't given at the time that there
was time to accept such feedback. You may say that going away for 15
years and then complaining is acceptable in some industries. It clearly
isn't in this.

It clearly*is*  the case and the reason companies are abandoning Qt
wholesale.

That's not a valid conclusion.

I can accept that in some industries what you're saying is true. I can even
accept that in those industries Qt was in use and now some companies in that
industry (even all of them) are abandoning Qt.
I did not say "all" companies I said companies. Certainly the vast 
majority of medical device manufacturers have given it the heave hoe. 
Customers Qt actively pursued.

So stop the FUD.

It's not FUD as others have pointed out. You didn't even know the stuff
Andre' needed was shot out of the saddle so quit claiming FUD. The
process is far more Willy-Nilly than measured. The decisions aren't
based on polling the customers and stuff is shot out of the saddle
without any viable replacement.

It's not done polling customers because that is not the process. But there is
a process. Again, you may not like the process, but there is one and therefore
it's not willy-nilly.

I do not deny we've removed stuff. I am asking that you stop calling it willy-
nilly because:


https://www.merriam-webster.com/dictionary/willy-nilly

1*: *by compulsion *: *without choice

2 *: *in a haphazard or spontaneous manner

Neither applies.


Both apply.

I also need to point out comments of others about justifying 

[Interest] Frame count from MediaPlayer QML while playing

[Alex john]

Hello,

I would like to get the frame count of the video that's been played by
the MediaPlayer in QML, but I didn't find any property that will
provide it. As the video is made up of frames , I have corresponding
annotations per frame in the database that I would like to fetch using
the frame number as index. Any way I could access the frame count?
(the current frame number thats rendered)
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest