When using NoFontMerging, no fallbacks should be resolved. If the
font does not support a specific character in the text, we should
display a box instead of merging it with another font.
But in practice, Qt would still apply the fallback mechanism for
one specific case: If the font itself does not support the script
of the text, we would get no match and do a search for a fallback
instead. Since NoFontMerging is set, we would then force this
as preresolved for *all* scripts in the QFont's private data
(logically, the match should only have a single response for
NoFontMerging).
The end result was that if you set the font family before updating
the text, you would get broken rendering. This can happen e.g. in
Qt Quick, where you could update the font family of a text label
while it contains characters which are not supported by the new
font. Qt would then pick a fallback instead. When you subsequently
update the text, the fallback would already be preresolved for
whatever script this is. If it does not support the updated text,
we would then see boxes, even if the requested font actually would
have supported it.
The fix is simply to do an additional pass if NoFontMerging is set
and we were not able to match with the specified script. Since
the same family might be available in different foundries, with
different writing system support, we still want to do a pass first
to see if we can match the exact script of the text.
Note that QRawFont::fromFont() exploited the bug by using
NoFontMerging for getting the fallback font for a specific
writing system. To keep this working without having to rewrite
fromFont() and risk introducing regressions, we add an argument
to make the findFont() function behave as before. It isn't
super-pretty, but since it is private API it is hopefully fine.
[ChangeLog][QtGui][Text] Fixed an issue with NoFontMerging and
changing font families dynamically, where boxes would be seen in
place of the correct text.
Pick-to: 5.15 6.1 6.2
Done-with: Andy Shaw
Fixes: QTBUG-81770
Change-Id: Ide9a36d7528a1040172c5864fa99e7a82eac4e83
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Size 0 is a "valid" answer for QIODevice implementations so we need to
make sure that we only enter the "try to workaround broken files" if we
know there is a size, otherwise the first read of length 4 that libpng
does breaks everything.
Change-Id: I1e396abd206ff90edae4372726f1d82d5d41ccf3
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Like we do for OpenGL. Conveniently enough the QRhi feature flags are
readily available.
This should prevent errors such as:
MTLValidateFeatureSupport:3901: failed assertion `Base Vertex Instance
Drawing is not supported on this device'
on the iOS Simulator. It is not clear since which version or SDK this
became a fatal problem, but the base vertex/instance support is indeed
an optional feature according to the Metal Feature set tables, so not
calling the drawIndexedPrimitives variant taking baseVertex and
baseInstance when the reported iOS GPU family is too low is the right
thing to do regardless.
Pick-to: 6.2 6.1
Fixes: QTBUG-95795
Change-Id: I47c54a77a66a0410b86b8d4e5a1863dc730490f4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
This avoids rebuilding the same pattern. Caught by clazy.
Change-Id: Ibd0f2063617df1a9e975f58e34df556d1983afff
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The documention currently incorrectly lists QNativeInterface::QX11Application
as available since 6.0.
Pick-to: 6.2
Change-Id: I13256a1504b2bd93296434438835791f12353089
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
On high-dpi displays or when you explicitly select an unhinted font,
we pick a DirectWrite font engine. This hit an uncovered code path
on Windows, because we relied on being able to get the HFONT from
the font engine.
To fix this, we introduce an alternative code path which gets the
HFONT based on the DirectWrite font when this font engine is active.
[ChangeLog][Windows] Fixed an issue where the characters in printed
text would look too small.
Pick-to: 6.1 6.2
Fixes: QTBUG-95720
Change-Id: Ifd609e92512e1f25f0ee2aace35cb5ccedf09030
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
When a key press comes in we may end up in QAppleKeyMapper::possibleKeys()
as part of checking whether the key press should trigger a QShortcut.
The function builds on QAppleKeyMapper::keyMapForKey(), which provides
a map from the given virtual key to all the possible Qt::Keys that can
be produced by applying different modifier key combinations.
The map is built using the Carbon function UCKeyTranslate, that takes
the current keyboard layout, virtual key, and modifiers, and produces
the resulting characters. The function also maintains a running dead
key state via one of the arguments. When mapping a dead key, the state
variable will be updated to the current dead key state, which then
affects the next call to the function (for the next key press).
The problem is that we're not calling UCKeyTranslate for each key press.
We are calling it in a loop, for a single key press, to build up a map
of all the possible characters produced by varying the modifier keys.
And in doing so, we are passing on the dead key state from one call
to the next, even if these are for different modifiers. The result is
that the first call, for the dead key, results in mapping to \0, as
UCKeyTranslate produces no output, it only modifies the dead key state.
And then the next call, for the next modifier key combination, results
in mapping to a character that incorrectly incorporates the dead key
state (resetting it in the process).
What we really want is to directly map the initial modifier combination
to the dead key terminator character, if one is defined. This is the
character produced if the dead key state is cancelled, for example by
pressing a key that's not defined in the dead key state.
To achieve this we pass kUCKeyTranslateNoDeadKeysMask as the translate
options to UCKeyTranslate, and always reset the dead key state before
every call. Another common way to achieve the same result would be to
call UCKeyTranslate a second time when detecting that the first call
produced a dead key state, for example with a synthetic space key, to
trigger the terminator output. But this can potentially fail if the
space key actually has a defined output in the dead key state.
Fixes: QTBUG-95471
Pick-to: 6.2 6.1
Change-Id: Icdae7639fd9a641a86c9d6615679bd93d380ff5c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
When mapping virtual keys and modifiers to their corresponding characters
via a keyboard layout we may hit combinations that do not produce any
characters. This can happen if there's no <key> element defined for the
virtual key, or if the output attribute of the element is empty (despite
the spec saying there should always be one UTF-16 code point in the output).
https://developer.apple.com/library/archive/technotes/tn2056/_index.html
When that happens QAppleKeyMapper::keyMapForKey() will map the combination
to a null-QChar, resulting in the "key" being 0. We do not want to propagate
this back to the QShortcutMap machinery, as QShortcutMap does not validate
the keys coming out of QKeyMapper::possibleKeys(). In particular, it doesn't
check the isEmpty() or count() of the QKeySequences it creates. And even if
it did, QKeySequence itself seems to treat Qt::Key(0) + Qt::SomeModifier
as a non-empty sequence, so passing on 0-keys would still give weird bugs.
The user-visible result of passing back 0-keys is that QShortcutMap will
treat it as a partial match for any incoming key combination (as long as
some modifier is pressed that triggers the QShortcutMap machinery), which
resulting in eating the key press. This compounded the issue in QTBUG-95471.
Regression after fab3dfff7d.
Task-number: QTBUG-95471
Pick-to: 6.1 6.2
Change-Id: I2e51ec86f4df2a708e1757be827ab74859be3c8b
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The "locked" flag was only added for a particular use in the Freetype
font engine in 070d9c00c488a5ee6811f04170cf488ead79bf80,but that usage
was refactored away long ago in afb326f071.
Pick-to: 6.2
Change-Id: I7347c91f49ba59041f6ff35bd5a6b537d6c704d4
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The local/global positions for gestures should be handled the same as
for other events as they mean effectively the same thing.
Change-Id: Ic5ad995607ecd3daf385a7c7be3b67cbae312e7b
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
CreateDXGIFactory2() is always available from Windows 8.1
No need to load it dynamically.
Pick-to: 6.2
Task-number: QTBUG-84432
Change-Id: I84d82f30327df416e1fdbac256b63512900c07b7
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Previous fix hit too widely so some valid horizontal and vertical
lines were affected; the root problem being that such lines have an
empty control point rect (width or height is 0). Fix by caculating in
the pen width.
Pick-to: 6.2 6.1 5.15
Change-Id: I7a436e873f6d485028f6759d0e2c6456f07eebdc
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The {mouse,touch}DoubleXDistance variables were initialized to -1,
which forces them into the DATA segments.
But this value is completely unused, since these variables are also
set in initThemeHints(), called from QGuiApplicationPrivate::init(),
before their only user, QGuiApplicationPrivate::processMouseEvent(),
can possibly execute.
By changing the default value to 0, then, we allow the compiler to
place these variables into the BSS segment.
Change-Id: I86144559ee2410b844f70a4f2499c8d3140d14cf
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Instead of appending to a QByteArray and then streaming that one, just
stream the components of a line directly. QTextStream's op<<(const
char*) is not subject to QT_NO_CAST_FROM_ASCII, etc., so can be used
unconditionally.
Change-Id: Idd97a75a1b5b939de7176d40880a2f328d01927d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The major use-case of the now private QX11Info from Qt X11 Extras was
getting hold of the Xlib display and XCB connection, for example in KDE:
https://lxr.kde.org/search?%21v=kf5-qt5&_filestring=&_string=QX11Info
A new native interface for QGuiApplication has now been added that
exposes these two properties, e.g.:
if (auto *x11App = app.nativeInterface<QX11Application>())
qDebug() << x11App->display() << x11App->connection();
To avoid type clashes one of the enum values of QXcbNativeInterface's
ResourceType had to be renamed.
Pick-to: 6.2
Task-number: QTBUG-93633
Change-Id: I2e366a2bb88bd3965ac6172ad000ae32209f43e7
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The following code assumed, and all comments indicated, that the cpp
variable was limited to a max of 4. Yet, as coded, cpp could be five,
in which case the XPM would be corrupt, as the header suggested five
characters-per-pixel while the data was formatted in only four.
Add a warning and error out when we encounter this situation.
[ChangeLog][QtGui][QImage] Instead of writing a corrupt file, rejects
to write XPM files with more than 64^4 colors (more than four
characters per pixel) now.
Pick-to: 6.2 6.1 5.15 5.12
Change-Id: I458873cf7d179ab2e2dacd4c17dc837d640591a9
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's private API, but exported, so de-inline the dtor to pin the
vtable in QtCore instead of potentially duplicating it in every plugin
that uses the class.
Change-Id: Ia948985bb94677c8453a8e7be27a14085303aaf5
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Resize QPlatformWindow on DPI change, so that QWindow
size can stay approximately constant.
For example, a 100x100 QWindow at 100% scaling will
have a 100x100 QPlatformWindow. If the scaling is changed
to 200% then the QPlatformWindow is resized to 200x200,
while the size of the QWindow stays at at 100x100.
In practice the QWindow size will also change slightly,
due to inaccuracies in how we adjust for the size of the
non-client window area. This will be addressed in a later commit.
We can get DPI change independently of screen change,
so no resizing should happen in screen change events.
Disable the resize code in QGuiApplication for Q_OS_WIN,
and remove the WithinDpiChanged flag.
The new flow for handling DPI change is:
1) Send screen change (if any), so that the correct
screen will be used when calculating scale factors
during the following resize.
2) Resize the native window, which will trigger geometry
change events, possibly also for the QWindow.
3) Resize child windows; WM_DPICHANGED is sent to
top-level windows only.
Fixes: QTBUG-89294
Pick-to: 6.2
Change-Id: I0e2d44bae72d20ebdafc3d410db7be9964ad851b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
... instead of *(array + index).
Also fix a pointless cast from QRgb to int which the next line
implicitly undoes (because colorMap has QRgb as key, not int) and get
rid of the local variables that facilitated said fallacy in the first
place.
Change-Id: I71a92822ee2404646f6fb5533e40252f38e6b21f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
... and fix spacing around operators and after flow-control keywords.
Change-Id: Iefaa03074536d13a655c91fb42aef6aa96c2665b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The code used the if (!contains()) { insert() } anti-pattern,
necessitated by Qt's deviation from the STL of allowing insert() to
overwrite an existing entry, causing two lookups of the same key.
Since QMap these days is a wrapper around std::map, fix by using the
real thing (a std::map) instead, which sports the non-broken insert()
semantics already, avoiding the need to play tricks like detecting a
size increase in order to find whether an insertion took place. It
also simplifies the loop later on, and we can transparently use pmr,
when available.
Change-Id: Iedd8d5691514a7705a55c27376446304b20af071
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
... and use one variable definition per line.
Change-Id: Ie8e6d6fb9e570cf715ab0b39c78d677f1e5a19a7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The xpm_color_name() function returned a pointer to a function-static
buffer. This is infamously non-reentrant, and an actual problem,
because we explicitly allow QImage operations (incl. saving to an
.xpm) from non-GUI-threads.
Fix by using the CSS pattern (Caller-Supplied Storage; also used in
the QAnyStringView(char32_t) and QAnyStringView(QStringBuilder) ctors)
to force the caller to allocate storage in its own stack frame. As a
consequence, we re-gain re-entrancy, but the returned pointer is now
only valid until the end of the full-expression, which necessitated
simplifying one caller (sorry!).
To see why said simplification is valid, observe that xpm_color_name()
writes a (now-explicit) NUL into returnable[cpp] and the old code read
max(cpp, 4) characters from xpm_color_name()'s result.
NB: cpp can be 5, even though the code comments say otherwise! :(
[ChangeLog][QtGui][QImage] Fixed a race condition when concurrently
writing .xpm files.
Pick-to: 6.2 6.1 5.15 5.12
Change-Id: I36d7173d53839a52f5cdf58324474c1b32c71f33
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In order to filter out file names based on the user's settings,
QFileSystemModel used to have a loop that tested if a given file
name matched one of the filters. The problem is that each filter
(a wildcard) was converted to a QRegularExpression _inside_ the loop.
This causes a quadratic behavior (number of files * number of filters).
Instead, build the regexps once when the filters are set (or the case
sensitivity is changed, as that affects the filtering), and simply
_use_ them in the loop.
Simplify and correct some related code as a drive by.
Done-with: Jean-Michaël Celerier
Fixes: QTBUG-95383
Pick-to: 6.2 6.1 5.15
Change-Id: I6bc336364c145bb05793a8f867545d7715d35832
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
One is a bad application or library in this case, but nonetheless
we should handle this more gracefully then just crashing due to
the QRhi already having been destroyed. Mainly because in Qt 5 one
could get away with the same: releasing OpenGL objects underneath,
for example, a QSGPlainTexture with no (or wrong) GL context did
not generate any user visible fatal errors. So we should not crash
in Qt 6 either with these code bases.
In debug builds or when QT_RHI_LEAK_CHECK is set, one will get the
unreleased resources warning printed in Qt 6, which is a step
forward compared to Qt 5. So there is still some indication that
something is badly designed, even if the application survives.
Task-number: QTBUG-95394
Pick-to: 6.2
Change-Id: I944f4f425ff126e7363a82aff926b280ccf1dfc3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
It would have been nice to ensure that a device is registered already in
mouseEnteredImpl(); but in that context, NSEvent.deviceID is always 0,
and we can't find out anything else about the device.
QWindowSystemInterface::handleEnterEvent() doesn't currently take a
QPointingDevice either.
In handleMouseEvent() and scrollWheel(), deviceID seems unique for each
trackpad or Magic Mouse, but 0 for any plain USB mouse. There, the first
mouse that the user interacts with becomes primaryPointingDevice():
its deviceID is assigned to systemID (except if deviceID == 0, we use
1 instead, to avoid the auto-incrementing device ID assignment in the
QInputDevicePrivate ctor.) When scrolling occurs, we update the
capabilities to have PixelScroll if theEvent.hasPreciseScrollingDeltas.
So over time, QInputDevice::devices() should build up to a complete
list, with capabilities() also distinguishing plain mice from those that
have the PixelScroll capability. And in the common case that the user
has only one Apple pointing device, it becomes primaryPointingDevice().
Pick-to: 6.2
Task-number: QTBUG-46412
Task-number: QTBUG-63363
Task-number: QTBUG-72167
Change-Id: Id9771b4dfd765e49023bd57d42a2aa4d0635a3b2
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Apart from a more fitting, minimal, API, QDuplicateTracker also
transparently uses C++17 pmr::monotonic_buffer_resource to avoid, or
at least reduce, memory allocations.
Change-Id: I155f5518190c5f8f6d21fbec3fcecd6bcc7ff852
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
If Vulkan headers are present on the system when qtbase is configured,
QtGui and QtOpenGL should be compiled with Vulkan support.
If a user project uses a Qt built with Vulkan support, but their system
is missing Vulkan headers, the project configuration needs to succeed.
The project will get compilation errors if it uses Vulkan headers, but
that's intended.
This use case was broken when fixing Vulkan to be found when building
Qt for Android.
Fix the regression with a combination of things
1) Mark the WrapVulkanHeaders package as optional (already the case)
2) Use the include directories directly when compiling Gui and OpenGL
3) Propagate WrapVulkanHeaders::WrapVulkanHeaders link requirement to
consumers only if the target exists. It won't exist if Vulkan
include dirs are not found
This also requires some changes in pri and prl file generation.
For prl file generation, we don't want to link to the
WrapVulkanHeaders target, so we filter out all dependencies that
use TARGET_NAME_IF_EXISTS for anything that calls
__qt_internal_walk_libs which includes qt_collect_libs.
For pri files, we make sure to generate a uses=vulkan/nolink clause
by inspecting a new _qt_is_nolink_target property on the target.
We also don't add include dirs to the pri file if the new
_qt_skip_include_dir_for_pri property is set.
This is intended for Vulkan, because there is separate qmake logic to
try and find the include dirs when configuring a user project.
As a drive-by, fix nolink handling for WrapOpenSSLHeaders.
Amends bb25536a3d
Amends 7b9904849f
Pick-to: 6.2
Fixes: QTBUG-95391
Change-Id: I21e2f4be5c386f9e40033e4691f4786a91ba0e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
When xdg-open is not found the KDE-specific kfmclient is considered.
That however is part of Konqueror and may not be present as well.
Plasma offers another option, kde-open5, which should be considered
before falling back to webbrowsers.
This is particularly for non-http URLs like tel: where opening in a
webbrowser is not wanted.
Pick-to: 6.2 6.1 5.15
Change-Id: I2b606562e21568fbe43f4593de67a1d467918cc4
Reviewed-by: David Faure <david.faure@kdab.com>
Before this change, next() was the only way to advance the iterator,
whether the caller was ultimately interested in just the filePath()
(good) or not (bad luck, had to call .fileInfo()).
Add a new function, nextFileInfo(), with returns fileInfo() instead.
Incidentally, the returned object has already been constructed as part
of advance()ing the iterator, so the new function is faster than
next() even if the result is ignored, because we're not calculating a
QString result the caller may not be interested in.
Use the new function around the code.
Fix a couple of cases of next(); fileInfo().filePath() (just use
next()'s return value) as a drive-by.
[ChangeLog][QtCore][QDirIterator] Added nextFileInfo(), which is like
next(), but returns fileInfo() instead of filePath().
Change-Id: I601220575961169b44139fc55b9eae6c3197afb4
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Some pathological cases were not caught by the previous fix.
Fixes: QTBUG-95239
Pick-to: 6.2 6.1 5.15
Change-Id: I0337ee3923ff93ccb36c4d7b810a9c0667354cc5
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Added missing #if-ery and deprecation macros to a QFont constructor
that was only documented as deprecated.
Fixes: QTBUG-94521
Fixes: QTBUG-95310
Pick-to: 6.2 6.1
Change-Id: I3d0418a3f7dca191a9068cc22627fe4deb7c53c5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
All other equality comparisons except floating-point are value
comparisons, not interpretation comparisons.
[ChangeLog][QColor] Equality on HSL colors is now raw value
based like other color-formats, instead of being partially
interpretation based.
Pick-to: 6.2
Change-Id: I391464da172af6a2d69178b94203d36f7ce2c07d
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The fontFamilies and fontStyleName have an asymmetric getter and setter.
The setter takes QStringList, but the getter returns QVariant (?), for
no reason whatsoever (the underlying QFont APIs take QStringList,
and the docs say that they should return QStringList).
It's not entirely obvious that we can fix this without introducing
badly-named getters (getX) or somesuch, so for the time being, mark
this to be fixed in Qt 7.
Change-Id: I49706af00906a2c5d950ada4be3cbc76dbee432c
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Fixes static analyzer warning 12b19393e18b2394a398806f633c6eee, and
amends a1a6e3d21b.
In the process, replace the "int& *= double" with correct integer
arithmetic that'll produce the intended result without going via
double.
Done-with: Edward Welbourne <edward.welbourne@qt.io>
Pick-to: 6.2
Task-number: QTBUG-8096
Change-Id: Ib2aa8ae46a1bfd4d121e61cf99141c0311502215
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Spotted during API review for 6.2
Pick-to: 6.2
Change-Id: Ib31020848ec6ffabc126c6984cc82547266d4a1d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Declaration::lengthValue only supported 'px' sizes, but one can transform
any 'pt' value into 'px' by multiplying with 1.33.
Notes: this ignores display DPI, and instead follows the W3C definition
of 'pt' and 'px' as absolute lengths [1].
[1] https://www.w3.org/TR/css3-values/#absolute-lengths
1pt = 1/72th of 1 inch
1px = 1/96th of 1 inch
so the conversion is px = pt * (72/96).
Add unit test that verifies this using QPushButton's icon-sizes property,
also with changed font in preparation of adding support for 'em' and 'ex'
units in a follow up commit.
Task-number: QTBUG-8096
Pick-to: 6.2
Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io>
Change-Id: I58782e7ad0e2ff9d89ed695f8a23b1e584cfed64
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
The use of a freestanding function is not needed now that the name
doesn't alias the nativeInterface accessor function, and was just
adding complexity to the machinery.
People not familiar with the code will have an easier time following
the flow through the helper member function, and we no longer need
to declare our own export macros.
Pick-to: 6.2
Change-Id: I17530b7e89939cfc19ab8ffaa076b7129ae02dcf
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The switch condition expression has already dealt width all the
conditions, so a `default` label is not necessary (it introduces a
warning). Delete it.
Fixes: QTBUG-95223
Change-Id: Iac3d9bb5d0b6fd8372d4dc16d920ce0a7b0511db
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Replace a manually-managed pointer + size with QVarLengthArray,
allowing use of pre-allocated space.
Change-Id: Ife3abea0b3b0f2577bb76c348513d52d46f79641
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use unique_ptr to indicate ownership.
The QPainter dtor is now empty, = default it.
As a drive-by, fix a non-sensical if (p) p = nullptr;
Change-Id: I5c811eb7de6abf8a9f279cf3630d5f86db6b3864
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
We keep QVector2D storage Qt 6 BC (to avoid making QNativeGestureEvent
larger), but in Qt 7 we should return exactly the same value as given
(for what it's worth, in spite of this being overkill for panning a
reasonable distance).
Change-Id: Iecbd4c9b60ad9ae5e0466c7027b038ddb85b8c8b
Pick-to: 6.2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
By switching out the static_assert for an enable_if we end up producing
a clearer error, at the call site:
/qt/qtbase/examples/gui/rasterwindow/main.cpp:69:9: error: no matching member
function for call to 'nativeInterface'
app.nativeInterface<QNativeInterface::QCocoaGLContext>();
~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/qt/qtbase/src/gui/kernel/qguiapplication.h:176:5: note:
candidate template ignored: requirement
'NativeInterface<QNativeInterface::QCocoaGLContext>::isCompatibleWith<QGuiApplication>'
was not satisfied [with NativeInterface = QNativeInterface::QCocoaGLContext, TypeInfo =
QNativeInterface::Private::NativeInterface<QNativeInterface::QCocoaGLContext>, BaseType =
QGuiApplication]
QT_DECLARE_NATIVE_INTERFACE_ACCESSOR(QGuiApplication)
^
By using SFINAE for the TypeInfo we can also ensure that it works for
types that are not native interfaces, such as if the user tries to
call nativeInterface<QString>().
Since we can no longer use decltype(*this) to resolve the base type
we need to change QT_DECLARE_NATIVE_INTERFACE_ACCESSOR to take the
type as an argument, as we do for other QT_DECLARE_FOO macros.
Pick-to: 6.2
Change-Id: Ie3f7e01ab7c3eb3dcc2ef730834f268bb9e81e0c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Eskil Abrahamsen Blomfeldt
Albert Astals Cid
Laszlo Agocs
Waqar Ahmed
Jonas Kvinge
Tor Arne Vestbø
Eirik Aavitsland
Povilas Kanapickas
Yuhang Zhao
Tasuku Suzuki
Andy Shaw
Marc Mutz
Morten Johan Sørvig
Giuseppe D'Angelo
Shawn Rutledge
Oliver Wolff
Alexandru Croitor
Nicolas Fella
Robert Löhning
Nico Vertriest
Allan Sandfeld Jensen
Volker Hilsheimer
Ivan Solovev
WenTao Song