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
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
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
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 shoul
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 whe
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 t
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
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 d
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 i
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 com
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
understandi
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 i
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
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
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 qmltyp
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 t
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 electri
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
> 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'
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 manage
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).
W
21 matches
Mail list logo