In some circumstances our application badge code seems to throw an
exception. The issue is hard to reproduce but just catching the
exception should be enough to fall back to the "non-winrt" version of
the code.
Fixes: QTBUG-117091
Pick-to: 6.5 6.7
Change-Id: I61f4e59f7309e2bb47b50a6ca6f3099ed9cd0af1
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move storage of whether dark mode is set into a static class member
of QWindowsTheme, and remove QWindowsContext::isDarkMode; ask the
theme instead using the colorScheme() implementation, which will return
the stored value.
Move the code handling settings changes into QWindowsTheme as well.
Task-number: QTBUG-124490
Change-Id: I4795e80b6ab2c94701385dc84771e9ad5578cf32
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Like as QT_QPA_PLATFORM, supports specifying multiple keys, and can
perform fallback operations to prioritize the use of a certain plug-in.
This is useful when using Wayland and XWayland applications at the same
time. For an example, we can set "QT_IM_MODULES=wayland;fcitx", and the
wayland application will use the wayland input context plugin, the
xwayland application will use fcitx, which can't be done without adding
a new environment variable, if we specify "QT_IM_MODULE=wayland", the
XWayland applications may not be able to use the input method.
Fixes: QTBUG-120202
Change-Id: Iac408af241963147747a2fe685f1e27bf9d9ee64
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Edmundson <davidedmundson@kde.org>
This was a feature in Qt 4, but the only platform that carried it over
to Qt 5 was Windows, in ab76593f18, and
that's still the situation.
As a first step in possibly implementing this on more platforms, lets
replace the hard-coded check in QWidgetRepaintManager::hasStaticContents
with a proper QPlatformIntegration capability check in the only call site.
Pick-to: 6.7
Change-Id: I2067109f45116cd8c62facf7224cd748f19e845b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The GDI font backend is missing support for certain modern features,
and has a lot of work arounds for missing APIs. DirectWrite is the
modern way to handle fonts on Windows, so we make this the default
now, but keep the old backend as a fail safe.
Fixes: QTBUG-119420
Change-Id: I0ea5cdfdcd759ccc894efb01b2410826c44aa1ea
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lars Knoll <lars@knoll.priv.no>
The documentation about QWindowsIntegration is outdated since ages and
not used anywhere so remove it.
Pick-to: 6.7
Change-Id: I3addb77f2024bfc8239aa57a866e9bdb8afc8381
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Jaishree Vyas <jaishree.vyas@qt.io>
We need to re-apply the application badge when the color scheme changes;
when a task bar button is being created for the fist time; or after Explorer
has crashed and re-started.
But we should only do that if the user has set an application badge
via our APIs. Otherwise we might end up clearing an existing badge
that was set via the native APIs directly.
Fixes: QTBUG-118117
Pick-to: 6.5 6.6
Change-Id: I1f1fecba44c118d4e3f7ef4119139c3ebd23f047
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
It's possible that the window has the WS_THICKFRAME flag but the
Qt::FramelessWindowHint is enabled at the same time. That usually
indicates the user is customizing the window, but it will also
confuse QPA's current logic. We can make the logic more roboust
by reading the Qt window flags as well.
Pick-to: 6.5 6.4
Change-Id: I9894e312a92ef7f5fc0aa93974f216b67fe2cf29
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Qt6's minimum supported platform is Win10 1809, so it should be quite
safe to use DPI_AWARENESS_CONTEXT APIs because they were introduced
in Win10 1607.
This patch removes the use of the PROCESS_DPI_AWARENESS APIs because
they are old (introduced in Win8.1) and most importantly, they can't
handle the new PMv2 and GdiScaled awareness mode.
This refactor also fixed a bug: previously Qt is using GetProcessDpiAwareness()
to get the dpi awareness mode of the current process, however, that API can't
return PMv2, which means even if we are in PMv2 mode, it will still return PMv1
(I've confirmed that locally), and thus Qt is mishandling such cases.
Eg: when judging whether to enable non-client area dpi scaling or not.
Change-Id: I8a8946ba63c863f8c19c27998af2bac97db37ec7
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Can be overwritten by setting the "darkmode" parameter of the QPA
platform to 0 or 1. The Windows Vista style (which is the
default on Windows) will overwrite the platform theme's palette with the
light system palette (see a2518b4140), but
styles that support rendering in dark mode will just run with the dark
palette.
More work needed in qtdeclarative to make the Qt Quick native style for
Windows also overwrite the palette, and to handle palette changes in Qt.
[ChangeLog][Windows] Qt applications that use a style that supports
dark mode rendering (such as the classic Windows or Fusion styles) will
respect the dark appearance setting on Windows. Applications that use
the Vista style, which doesn't support rendering in dark mode, will
use the light system palette. On dark mode systems, the window frame
will be dark if the palette is dark.
Task-number: QTBUG-72028
Change-Id: I416b4fd59eb3f64701b403984c7ac2359536abbe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Certain older SDKs don't declare the specific wait_for overload but
still uses it. So, we declare it.
Also add the factorycacheregistration include to wipe out any factory
that may be created and cached in the TU.
Change-Id: I778ab1b8724306b17bb6a2daa0b7364f268ded83
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Calling QWindow::winId() will create the platform window if it hasn't
been created yet, which is not what we want.
Change-Id: I9d4ecb863f961fd3cef6d13e27bf175bf55eabcf
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The API is supported on macOS, iOS, and Windows. On Android no official
API exists for badging the application icon, and we don't want to take
on dependencies like ShortcutBadger [1].
The macOS and iOS implementations are trivial. The same goes for
the WinRT based implementation on Windows, but this API is only
available for applications that have a so called "package identity",
and does not seem to be stable for Windows 10.
To cover the cases where this API is not available we fall back to
drawing the badge manually, and set it as an overlay icon on the task
bar using ITaskbarList3. The look of this badge has been tweaked to
match the Windows 11/10 styles, and will pick up the user's choice of
dark/light mode and accent color if available.
[1] https://github.com/leolin310148/ShortcutBadger/
[ChangeLog][QtGui] Added QGuiApplication::setBadgeNumber() to inform
the user about e.g. the number of unread e-mail or queued tasks.
The badge will be overlaid on the application's icon in the Dock
on macOS, the home screen icon on iOS, or the task bar on Windows.
Task-number: QTBUG-94009
Change-Id: I6447d55177f9987b0dfcd93caf63c6167f7224c7
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This patch avoids synthesizing mouse messages in the QPA for touch/pen
input, and lets the GUI do mouse event synthesis for unhandled touch/pen
events, if required, like in other platforms. This requires a workaround
to avoid breaking drag and drop with touch/pen (or making it worse). DnD
on Windows is based on the DoDragDrop() Win32 API, which does not work
with touch/pen input, which in some cases cause a DnD operation started
with touch/pen to hang until the mouse is moved. To avoid it we process
pointer messages for touch/pen and generate mouse input through
SendInput() to trigger DoDragDrop(), which then seems to work as
expected.
So now we inform QtGui that the Windows platform no longer sends
synth-mouse events after tablet events (unsetting the flag added in
f931e5e72d); this completes what was
attempted in 8ada0633cd.
Fixes: QTBUG-106368
Fixes: QTBUG-57577
Fixes: QTBUG-100788
Task-number: QTBUG-77414
Task-number: QTBUG-104594
Pick-to: 6.4 6.3 6.2
Change-Id: I46db3c74be2a95cf2d94ba930398e58dc930d2db
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Other platforms name it singular 'qt.qpa.window'.
Change-Id: I668ed67e1686605fe5f77313c7a01c31fd574c32
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
43ef22045c turned dark mode support on for
both styling and window frames. However, the default palette and style
support in Qt is too incomplete, resulting in unreadable UIs when using
certain styles (e.g. fusion). Also the vista style is not supporting
dark mode.
If we don't turn on dark style support, then dark frame support doesn't
look good either. However, many application developers have implement a
dark theme themselves, and we should have a dark frame for those
applications.
So partially revert 43ef22045c so that
dark style support is disabled by default, and leave dark frame support
on. However, only activate dark frames if the palette is dark, i.e. if
the window background color in the default palette is darker than the
text color (or if DarkModeStyle is explicitly turned on by running the
application with -platform windows:darkmode=2).
This way, dark-themed applications get a dark frame on dark Windows, and
a light frame on light Windows; and light-themed applications (including
default Qt applications) get a light frame all the time.
Fixes: QTBUG-72028
Pick-to: 6.4
Change-Id: I61f1b1e43b2a4ba69848d5d8bec921c0790fe511
Reviewed-by: Marius Kittler <mariuskittler@gmx.de>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The implementation was already there, and handles theme changes at
runtime as well. However, it was disabled unless the QPA parameter
"darkmode" was set to either 1 (supporting only the frame) or 2 (the
Windows theme also supports dark mode when reading the palette).
With both Windows 10 and Windows 11 now having dark mode as a fully
supported feature that is easily accessible to end-users, we should
respect that setting by default.
So change the default: support both dark window frames and palette, and
let users turn this partially off by setting darkmode=1 or darkmode=0.
This does not mean accent colors etc are fully supported by the Windows
styles.
[ChangeLog][QtGui][Windows] Dark mode, both for the window frames and
for the palette, is now supported by default. It can be turned
off (partially or entirely) by setting the QPA parameter "darkmode=0"
(no dark mode support) or "darkmode=1" (darkmode support only for the
window frames).
Pick-to: 6.4
Fixes: QTBUG-72028
Change-Id: Ia55af101896c106cde21340b306aa81390e608a2
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The WM_DISPLAYCHANGE message it sent when displays are added, removed,
or update their properties such as the scale/DPI.
We were processing this message as part of QWindowsContext::windowsProc(),
which meant that we would only react to display changes if there was a
QWindow on screen. Just creating a QGuiApplication was insufficient to
pick up changes to screens after startup.
In addition, despite being documented to post messages to child windows,
WM_DISPLAYCHANGE only ends up in top level windows. Presumably it's the
top level window's responsibility to post the message to child windows.
As a result, if a QWindow was a native child window of a foreign window,
such as in audio plugins being hosted in a DAW, we would again fail to
pick up display changes.
We solve both these cases by decoupling the WM_DISPLAYCHANGE handling
from QWindowsContext::windowsProc(), by creating a dedicated window
for listening to WM_DISPLAYCHANGE. This is similar to how we already
handle tray icons, power notifications, clipboard, etc -- the only
difference being that since purely HWND_MESSAGE windows do not
receive WM_DISPLAYCHANGE it's an actual invisible WS_TILED window.
This also lets us remove the workaround for QTBUG-79248, which was
doing screen updates in response to WM_DPICHANGED when detecting
that there were no QWindows.
Task-number: QTBUG-103383
Task-number: QTBUG-79248
Fixes: QTBUG-102343
Pick-to: 6.4
Change-Id: I905d8253069ec339b193edf05c052d21361ca3e9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2 might not be supported
on some legacy Windows 10 editions (prior Creator Update). In this
case SetProcessDpiAwarenessContext returns ERROR_INVALID_PARAMETER.
Fallback to DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE using old API
SetProcessDpiAwareness in such cases as the most suitable.
Fixes: QTBUG-103733
Pick-to: 6.3 6.4
Change-Id: I39216e63ecfcae96aaa159237a52b0a76bc5d956
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Replace the current license disclaimer in files by
a SPDX-License-Identifier.
Files that have to be modified by hand are modified.
License files are organized under LICENSES directory.
Task-number: QTBUG-67283
Change-Id: Id880c92784c40f3bbde861c0d93f58151c18b9f1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
As a drive-by, fix qsizetype -> int narrowing conversion warnings for
the touched lines.
Task-number: QTBUG-98434
Change-Id: I7fadd3cf27ad099028d70f05956303e3af62c0f5
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
By changing it to unique_ptr.
Pick-to: 6.2 6.3
Change-Id: I91abb69445b537d4c95983ae735341882352b29d
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Mostly a removal of dynamically loaded Win32 APIs.
Since Qt 6's minimum supported platform is Win10 1809
(10.0.17763, code name RS5), all these functions will
be available and no need to resolve them at run-time.
Things not remove:
WinTab functions in "qwindowstabletsupport.cpp".
Not my familiar area, so not touch it.
Pick-to: 6.2
Task-number: QTBUG-84432
Change-Id: I7ad6c3bc8376f6c0e3ac90f34e22f7628efeb694
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Add support for opting in to PerMonitorV2 DPI awareness
on the command line:
-platform windows:dpiawareness=3
This mode is supported on Windows 10 and up. Setting it
requires using the new SetProcessDpiAwarenessContext
API, which can be resolved from user32.dll.
Task-number: QTBUG-68712
Change-Id: I37821e27a67e08c2e9fef25e494cfd7abed13314
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We were already using the 'native' nomenclature when referring to these
kinds of APIs, e.g. when talking about native handles, or the existing
QPlatformNativeInterface on a QPA level. Using 'native' for the user
facing APIs also distinguishes them from the 'platform' backend layer
in QPA and elsewhere.
Change-Id: I0f3273265904f0f19c0b6d62471f8820d3c3232e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Move options to new interface, making them settable from
code on this occasion.
Task-number: QTBUG-83252
Change-Id: Idd80667c502a8cde5d7c66d7e597ea34c22738e7
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Implement the static parts of QWindowsWindowFunctions.
Move some things around and make them static in tablet support
to make this easier.
Task-number: QTBUG-83252
Change-Id: I24c3b0b3c6548eb96c4f3285a4e46385a1e79ef5
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The API is available by including qopenglcontext.h as usual,
but scoped in the QPlatformInterface namespace. The namespace
exposes platform specific type-safe interfaces that provide:
a) Factory functions for adopting native contexts, e.g.
QCocoaGLContext::fromNative(nsContext, shareContext);
b) Access to underlying native handles, e.g.
openGLContext->platformInterface<QCocoaGLContext>->nativeContext()
c) Platform specific functionality, e.g.
static QWGLContext::openGLModuleHandle()
openGLContext->platformInterface<QEGLContext>->doSomething();
The platform interfaces live close to the classes they extend,
removing the need for complex indirection and plumbing, and
avoids kitchen-sink modules and APIs such as the extras modules,
QPlatformFunctions, or QPlatformNativeInterface.
In the case of QOpenGLContext these platform APIs are backed
by the platform plugin, so dynamic_cast is used to ensure the
platform plugin supports the requested interface, but this is
and implementation detail. The interface APIs are agnostic
to where the implementation lives, while still being available
to the user as part of the APIs they extend/augment.
The documentation will be restored when the dust settles.
Task-number: QTBUG-80233
Change-Id: Iac612403383991c4b24064332542a6e4bcbb3293
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
We have seen during the Qt 5 series that QMouseEvent::source() does
not provide enough information: if it is synthesized, it could have
come from any device for which mouse events are synthesized, not only
from a touchscreen. By providing in every QInputEvent as complete
information about the actual source device as possible, we will enable
very fine-tuned behavior in the object that handles each event.
Further, we would like to support multiple keyboards, pointing devices,
and named groups of devices that are known as "seats" in Wayland.
In Qt 5, QPA plugins registered each touchscreen as it was discovered.
Now we extend this pattern to all input devices. This new requirement
can be implemented gradually; for now, if a QTWSI input event is
received wtihout a device pointer, a default "core" device will be
created on-the-fly, and a warning emitted.
In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when
multiple devices were in use simultaneously. Now that each event
identifies the device it came from, this hack is no longer needed.
A stub of the new QPointerEvent is added; it will be developed further
in subsequent patches.
[ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer
to an instance of QInputDevice, or the subclass QPointingDevice in case
of mouse, touch and tablet events. Each platform plugin is expected to
create the device instances, register them, and provide valid pointers
with all input events. If this is not done, warnings are emitted and
default devices are created as necessary. When the device has accurate
information, it provides the opportunity to fine-tune behavior depending
on device type and capabilities: for example if a QMouseEvent is
synthesized from a touchscreen, the recipient can see which touchscreen
it came from. Each device also has a seatName to distinguish users on
multi-user windowing systems. Touchpoint IDs are no longer unique on
their own, but the combination of ID and device is.
Fixes: QTBUG-46412
Fixes: QTBUG-72167
Task-number: QTBUG-69433
Task-number: QTBUG-52430
Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Requires adapting a few config checks since cmake currently
does not detect directwrite.
Task-number: QTBUG-83255
Task-number: QTBUG-83931
Change-Id: I521f1924f701260b41dccbcecf87b19f08df5ccc
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This marks the end of EGL and OpenGL ES support on Windows.
The concepts of -opengl dynamic, -opengl desktop, QT_OPENGL=software,
etc. remain unchanged, with the exception of the disapperance of
everything ANGLE related.
CMake builds now work identically to qmake on Windows: they default to
'dynamic' OpenGL on Windows, unless -DINPUT_opengl=desktop is specified.
On Windows, Qt 6 is expected to default to the "dynamic" OpenGL model by
default, just like Qt 5.15. This can be changed by switching to "desktop"
OpenGL, which will link to opengl32 (publicly, so other libs and applications
will do so as well) and disallows using another OpenGL DLL.
The "dynamic" mode is essential still because the fallback to a software
rasterizer, such as the opengl32sw.dll we ship with the Qt packages,
has to to work exactly like in Qt 5, the removal of ANGLE does not
change this concept in any way (except of course that the middle option
of using ANGLE is now gone)
When it comes to the windows plugin's OpenGL blacklist feature, it works
like before and accepts the ANGLE/D3D related keywords. They will
then be ignored. Similarly, requesting QT_OPENGL=angle is ignored (but
will show a warning).
The D3D11 and DXGI configure time tests are removed: Qt 5.14 already
depends on D3D 11.1 and DXGI 1.3 headers being available unconditionally
on Win32 (in QRhi's D3D11 backend). No need to test for these.
[ChangeLog][Windows] ANGLE is no longer included with Qt. Dynamic OpenGL
builds work like before but ANGLE is no longer an option. OpenGL proper
or an alternative opengl32 implementation are the two remaining options
now. Attempting to set QT_OPENGL=angle or Qt::AA_UseOpenGLES will have
no effect on Windows.
Fixes: QTBUG-79103
Change-Id: Ia404e0d07f3fe191b27434d863c81180112ecb3b
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The QT_OPENGL_ES* macros are leftovers from an earlier,
ad hoc configuration system, which has since been
replaced by QT_CONFIG. To clean things up in Qt 6,
we use the new way instead.
Task-number: QTBUG-83467
Change-Id: I578dc7695bff9d5ee303b22e44f60fee22fe0c28
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This change adds the setWinTabEnabled() function to Qt Platform Headers,
which allows an application to set at run-time whether the WinTab API will
be used for tablet input instead of the native Windows Ink API.
[ChangeLog][Windows] The setWinTabEnabled() function added to Qt Platform
Headers now allows an application to set at run-time whether the WinTab API
will be used for tablet input instead of the native Windows Ink API.
Fixes: QTBUG-83218
Change-Id: I51d3c7316baeda136763cf37c2f54295905450ec
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Conflicts:
examples/opengl/doc/src/cube.qdoc
src/corelib/global/qlibraryinfo.cpp
src/corelib/text/qbytearray_p.h
src/corelib/text/qlocale_data_p.h
src/corelib/time/qhijricalendar_data_p.h
src/corelib/time/qjalalicalendar_data_p.h
src/corelib/time/qromancalendar_data_p.h
src/network/ssl/qsslcertificate.h
src/widgets/doc/src/graphicsview.qdoc
src/widgets/widgets/qcombobox.cpp
src/widgets/widgets/qcombobox.h
tests/auto/corelib/tools/qscopeguard/tst_qscopeguard.cpp
tests/auto/widgets/widgets/qcombobox/tst_qcombobox.cpp
tests/benchmarks/corelib/io/qdiriterator/qdiriterator.pro
tests/manual/diaglib/debugproxystyle.cpp
tests/manual/diaglib/qwidgetdump.cpp
tests/manual/diaglib/qwindowdump.cpp
tests/manual/diaglib/textdump.cpp
util/locale_database/cldr2qlocalexml.py
util/locale_database/qlocalexml.py
util/locale_database/qlocalexml2cpp.py
Resolution of util/locale_database/ are based on:
https://codereview.qt-project.org/c/qt/qtbase/+/294250
and src/corelib/{text,time}/*_data_p.h were then regenerated by
running those scripts.
Updated CMakeLists.txt in each of
tests/auto/corelib/serialization/qcborstreamreader/
tests/auto/corelib/serialization/qcborvalue/
tests/auto/gui/kernel/
and generated new ones in each of
tests/auto/gui/kernel/qaddpostroutine/
tests/auto/gui/kernel/qhighdpiscaling/
tests/libfuzzer/corelib/text/qregularexpression/optimize/
tests/libfuzzer/gui/painting/qcolorspace/fromiccprofile/
tests/libfuzzer/gui/text/qtextdocument/sethtml/
tests/libfuzzer/gui/text/qtextdocument/setmarkdown/
tests/libfuzzer/gui/text/qtextlayout/beginlayout/
by running util/cmake/pro2cmake.py on their changed .pro files.
Changed target name in
tests/auto/gui/kernel/qaction/qaction.pro
tests/auto/gui/kernel/qaction/qactiongroup.pro
tests/auto/gui/kernel/qshortcut/qshortcut.pro
to ensure unique target names for CMake
Changed tst_QComboBox::currentIndex to not test the
currentIndexChanged(QString), as that one does not exist in Qt 6
anymore.
Change-Id: I9a85705484855ae1dc874a81f49d27a50b0dcff7
Adds an opt-in experimental DirectWrite-based font database.
This cannot be the 100% replacement for GDI unfortunately, since
quite a few font formats used on Windows are still unsupported.
But it would be good to have it as an opt-in experimental feature
since it should make it easier to solve multiple font selection
issues we have on Windows.
In order to still share the DirectWrite-specific code between
the old and new database, this introduces a common base class.
Note that the feature depends on DirectWrite 3 support (Windows 10).
Fixes: QTBUG-74917
Change-Id: Ida08ec7ef4fda9fc78622ca4297909a727390a64
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Read the dark mode setting and make it accessible
via native interface.
Add a command line option to set the support level.
Task-number: QTBUG-72028
Change-Id: I1e9fe296a6b1bda81512d003183038b866b67545
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Oliver Wolff
Volker Hilsheimer
JiDe Zhang
Tor Arne Vestbø
Eskil Abrahamsen Blomfeldt
Christian Ehrlicher
Mårten Nordheim
Yuhang Zhao
André de la Rocha
Vladimir Belyavsky
Lucie Gérard
Sona Kurazyan
Morten Johan Sørvig
Friedemann Kleint
Shawn Rutledge
Lars Knoll
Laszlo Agocs
Qt Forward Merge Bot
Tor Arne Vestbø
Liang Qi