Re: [Interest] the path forward - that 7 year thing - was willy-nilly
On Friday, 26 March 2021 17:23:38 PDT Scott Bloom wrote: > 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 That's a distinction without a difference. You're saying you're unable to upgrade past 5.12 because a given compiler version became unsupported (that happened because those compilers were actually broken, not for lack of feature support, unlike the 5.6/5.7 change which was C++11). And you're saying the solution is to rename the next version 6.0. But you're not using that version, so what it is called is completely irrelevant. Meanwhile, those who can upgrade are thankful for not having to deal with the inevitable dot-oh issues. The difference, though, is this: > 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. Right. The lack of 5.15 updates right now is a problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 38
On 27/3/21 9:04 pm, Roland Hughes wrote: If I read Scott's original posts correctly, the compelling reason is a roughly $1 billion multi-year project was started and the OS physically cannot be changed out until that many year project is over. The UI can be updated and new functionality added. You get such projects in the industrial controls world. Generally custom device drivers for custom devices that are part of a production process. It is too expensive in terms of down time and development costs to switch to a new OS version. If memory serves he is talking about chip fabrication. Downtime is most likely measured at > $1 million per day. In the medical device world it is almost impossible to change out an OS without having to go down the "new product" approval process. That is lengthy and expensive. You can, because the design of the device mitigates RISK the UI could pose to patient safety/health, change out the UI library and go down the "minor enhancements" (I forget the correct name) FDA approval path. This is by no means free, but it is far less expensive and time consuming. If you __have__ to open the hood for a regulatory change, like the service password example I gave, most companies will try to freshen up the screen library to get better graphics and performance improvements. Every performance improvement can help extend battery life. On 3/26/2021 10:13 PM, interest-requ...@qt-project.org wrote: I still haven't seen any convincing argument on why you expect to use a brand new Qt with ancient compilers/OSs? None of that was an argument for upgrading Qt, just for not upgrading the rest. 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
On Friday, 26 March 2021 06:13:13 PDT 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. Well, maintaining is developing. If you're making adaptations to keep your software running, that probably counts. But I can't help you with the commercial licensing terms (which I've never seen). I suggest reaching out to your sales rep and informing of this issue. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML Image sourceSize bug (?)
On 27/03/2021 15:46, Alexander Dyagilev wrote:
If I enable mipmap, it looks much better comparing to original variant,
but still worse comparing to the final one (described in my original
posting).
I can provide you all the screenshots if you want to.
I can only entertain that mipmapping in your case is going to use
trilinear interpolation (*) between the 32x32 and the 16x16 mip. And,
for your particular image ("artwork" / "icon"), that is giving you worse
results than a 27x27 image scaled directly from the source via bilinear
interpolation.
There's not much to do about this:
* mipmapping allows you to keep a good visual quality if the displayed
size of the image changes
* sourceSize allows you to get a good scaled-down version and save on
memory, but will look awful if now you try to make the image bigger again
(*) didn't check the actual code, just assumed a GL_LINEAR_MIPMAP_LINEAR
setting.
HTH,
--
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
Re: [Interest] QML Image sourceSize bug (?)
First, thank you for your answers :) If I enable mipmap, it looks much better comparing to original variant, but still worse comparing to the final one (described in my original posting). I can provide you all the screenshots if you want to. On 3/27/2021 4:35 PM, Giuseppe D'Angelo wrote: On 27/03/2021 11:56, Alexander Dyagilev wrote: No. On 3/27/2021 1:24 PM, Giuseppe D'Angelo via Interest wrote: On 27/03/2021 04:20, Alexander Dyagilev wrote: Looks better. Why is it so? Did you enable mipmapping for the first one? Well, does it improve it you enable it? Thanks, ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Are Qt.transparent and "transparent" different colors?
On 27/03/2021 11:58, Alexander Dyagilev wrote: Hmmm... What is this enum for then? In C++ APIs, it's used in QColor's constructor. In QML, enumeration types are strange beasts (and I wish they weren't), sometimes being enum and sometimes being integers. I suggest to open a bug report suggesting to add a Qt::Color -> color type construction (assuming it's possible), because it's indeed supposed to "just work". (On the other hand, clearly, int->color should never work.) Thanks, -- 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
Re: [Interest] QML Image sourceSize bug (?)
On 27/03/2021 11:56, Alexander Dyagilev wrote: No. On 3/27/2021 1:24 PM, Giuseppe D'Angelo via Interest wrote: On 27/03/2021 04:20, Alexander Dyagilev wrote: Looks better. Why is it so? Did you enable mipmapping for the first one? Well, does it improve it you enable it? Thanks, -- 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
Re: [Interest] Are Qt.transparent and "transparent" different colors?
Hmmm... What is this enum for then?
On 3/27/2021 1:27 PM, Giuseppe D'Angelo via Interest wrote:
On 27/03/2021 07:00, Alexander Dyagilev wrote:
Rectangle {color: "transparent"} - getting transparent rectangle
This is fine.
Rectangle {color: Qt.transparent} - getting rectangle filled with white
color
This one is illegal. You can't set an enum or an int to a "color" type
in QML.
https://doc.qt.io/qt-5/qml-color.html
You are getting an error message on the console.
HTH,
___
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] QML Image sourceSize bug (?)
No. On 3/27/2021 1:24 PM, Giuseppe D'Angelo via Interest wrote: On 27/03/2021 04:20, Alexander Dyagilev wrote: Looks better. Why is it so? Did you enable mipmapping for the first one? Thanks, ___ 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] Are Qt.transparent and "transparent" different colors?
On 27/03/2021 07:00, Alexander Dyagilev wrote:
Rectangle {color: "transparent"} - getting transparent rectangle
This is fine.
Rectangle {color: Qt.transparent} - getting rectangle filled with white
color
This one is illegal. You can't set an enum or an int to a "color" type
in QML.
https://doc.qt.io/qt-5/qml-color.html
You are getting an error message on the console.
HTH,
--
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
Re: [Interest] QML Image sourceSize bug (?)
On 27/03/2021 04:20, Alexander Dyagilev wrote: Looks better. Why is it so? Did you enable mipmapping for the first one? Thanks, -- 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
Re: [Interest] Interest Digest, Vol 114, Issue 39
So, Just to be clear. You are saying QtC has the latest version of Qt 5.x compiling and running on Scott's RHEL version though Qt-project does not? That somewhere inside QtC all the compiler and OS versions abandoned by Qt-project mid Qt 5 have shiny happy versions of the latest 5.x? If one defines "platform" as compiler version + OS version (to make wording simple) it would seem to me that one Qt-project abandoned it and started writing to newer compiler and platform version it would become impossible to make a working fork. We had this problem with compiler standards quite a few years ago. C++11 was supposed to be the minimum supported but the CI was (and probably still is) compiling with only the latest standard. I ran headlong into this when people were using stuff from from a much later C++ standard in the examples and I think a few other places. Once they start using things that don't exist, or worse, exist differently, getting there from here is a very difficult journey. On 3/27/2021 3:23 AM, interest-requ...@qt-project.org wrote: “When Qt chased these markets it knew what the lifetimes would be. Now it has abandoned them.” I would like to point out that this is not a true statement. We do offer long term support and also extended support for those customers who need it. There are some who every now and then still need something related to Qt 3. Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain about that. Qt 4 based systems of course and majority of customers are with Qt 5 currently. Each of these versions has changed API and we have tried our best to make the transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and feedback to it still and help in the transition. -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 38
If I read Scott's original posts correctly, the compelling reason is a roughly $1 billion multi-year project was started and the OS physically cannot be changed out until that many year project is over. The UI can be updated and new functionality added. You get such projects in the industrial controls world. Generally custom device drivers for custom devices that are part of a production process. It is too expensive in terms of down time and development costs to switch to a new OS version. If memory serves he is talking about chip fabrication. Downtime is most likely measured at > $1 million per day. In the medical device world it is almost impossible to change out an OS without having to go down the "new product" approval process. That is lengthy and expensive. You can, because the design of the device mitigates RISK the UI could pose to patient safety/health, change out the UI library and go down the "minor enhancements" (I forget the correct name) FDA approval path. This is by no means free, but it is far less expensive and time consuming. If you __have__ to open the hood for a regulatory change, like the service password example I gave, most companies will try to freshen up the screen library to get better graphics and performance improvements. Every performance improvement can help extend battery life. On 3/26/2021 10:13 PM, interest-requ...@qt-project.org wrote: I still haven't seen any convincing argument on why you expect to use a brand new Qt with ancient compilers/OSs? -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ 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
Thanks Scott! Yeah, I was thinking about this as I woke up this morning. Trying to retroactively invalidate all existing perpetual licenses would be illegal. Not just "pay a fine" illegal, go to prison illegal. On 3/26/2021 7:30 PM, Scott Bloom wrote: 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 -- Roland Hughes, President Logikal Solutions (630)-205-1593 (cell) http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com ___ 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
“When Qt chased these markets it knew what the lifetimes would be. Now it has abandoned them.” I would like to point out that this is not a true statement. We do offer long term support and also extended support for those customers who need it. There are some who every now and then still need something related to Qt 3. Somewhere Qt 2 is still in use. Perhaps Qt 1 even, but personally not certain about that. Qt 4 based systems of course and majority of customers are with Qt 5 currently. Each of these versions has changed API and we have tried our best to make the transition from Qt 5 to Qt 6 smooth. We are happy to get suggestions and feedback to it still and help in the transition. Yours, Tuukka Lähettäjä: Interest käyttäjän Roland Hughes puolesta Lähetetty: Friday, March 26, 2021 10:47:34 PM Vastaanottaja: interest@qt-project.org ; mike.jack...@bluequartz.net Aihe: Re: [Interest] the path forward - that 7 year thing - was, , willy-nilly 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
Re: [Interest] QML Image size vs sourceSize strange things
OK, thank you. We do use SVGs (but sometimes also PNGs).
However, these PNGs I was talking about in the original posting are
files icons from system. I can't replace them with SVGs. :)
On 3/27/2021 9:51 AM, Nuno Santos wrote:
I had the same problem with blurry images on retina displays. I ended
up creating a image component that inside was by default setting
source size for twice the width and height of the item size to have
good results on iOS screens.
However..
I have recently found that replacing the pngs for svgs has accelerated
the UI loading time from seconds to a snap!!!
I have found this because I was not finding acceptable the time it
took to resize a window.
I had to replace years of pngs into svgs but in the end it payed off.
You should definitely consider moving to svgs.
Best,
--
Nuno Santos
No dia 27/03/2021, às 03:17, Alexander Dyagilev
escreveu:
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
mailto:alervd...@gmail.com>> 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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML Image size vs sourceSize strange things
I had the same problem with blurry images on retina displays. I ended up
creating a image component that inside was by default setting source size for
twice the width and height of the item size to have good results on iOS screens.
However..
I have recently found that replacing the pngs for svgs has accelerated the UI
loading time from seconds to a snap!!!
I have found this because I was not finding acceptable the time it took to
resize a window.
I had to replace years of pngs into svgs but in the end it payed off.
You should definitely consider moving to svgs.
Best,
--
Nuno Santos
> No dia 27/03/2021, às 03:17, Alexander Dyagilev
> escreveu:
>
>
> 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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] Are Qt.transparent and "transparent" different colors?
Hello,
Why the same name then?
Rectangle {color: "transparent"} - getting transparent rectangle
Rectangle {color: Qt.transparent} - getting rectangle filled with white
color
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
