Remove a magic number from the code, by adding it (as a private value)
to the right enumeration. Use toInt() to convert to integer.
Change-Id: Id1b00dde900619684b5a3df247d46938439150ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Either be explicit, or just use QFlags directly.
Change-Id: I18cbea4eaa1a0a4bce7665b735e7d785f7a196b2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rather than forcing an implicit conversion to int, accept a QFlags
(over either one of the two enumerations) directly.
Change-Id: I56af3a85982ecb66369e4a7105d07de0d6e0c40a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The initial approach for providing public access to native
interfaces via T::nativeInteface<I>() was based on the template
not being defined, and then having explicit instantiations of
the supported types in a source file, so that the accessors
were exported and available to the user.
This worked fine for "simple" types such as QOpenGLContext
and QOffscreenSurface, but presented a problem in the context
of classes with subclasses, such as Q{Core,Gui}Application.
To ensure that a native interface for QCoreApplication was
accessible both from QCoreApplication and its subclasses,
while at the same time preventing a native interface for
QGuiApplication to be accessible for QCoreApplication, the
nativeInterface() template function had to be declared in
each subclass. Which in turn meant specializing each native
interface once for each subclass it was available in.
This quickly became tedious to manage, and the requirements
for exposing a new native interface wasn't very clear with
all these template specializations and explicit instantiations
spread around.
To improve on this situation, while also squashing a few
other birds at the same time, we change the approach to
use type erasure. The definition of T::nativeInteface<I>()
is now inline, passing on the requested interface to a per
type (T, not I) helper function, with the interface type
flattened to a std::type_info.
The type_info requested by the user is then compared to the
available types in a single per-type (T) "switch statement",
which is a lot easier to follow for someone trying to trace
the logic of how a native interface is resolved.
We can safely rely on type_info being stable between the user
application and the Qt library as a result of exporting the
type info for each native interface, by explicitly ensuring
they have a key function. This is the same mechanism that
ensures we can safely dynamic_cast these interfaces, even
across library boundaries.
The use of a free standing templated helper function instead
of a member function in the type T, is to avoid shadowing issues,
and to not pollute the class namespace of T with the helper
function.
Since we are already changing the plumbing for how a user
resolves a native interface for a type T, we take the opportunity
to add a few extra safeguards to the machinery.
First, we add a static assert in the T::nativeInteface<I>()
definition, that ensures that only compatible interfaces,
as declared by the interface themselves, are allowed.
This ensures a compile time error when an incompatible
interface is requested, which improves on the link time
errors we had prior to this patch, and also offsets the
one downside of type erasure, namely that errors are only
caught at runtime.
Secondly, each interface meant for public consumption through
T::nativeInteface<I>() is declared with a revision, which
is checked when requesting the interface. This allows us
to bump the revision when we make breaking changes to the
interface that would have otherwise been binary incompatible.
Since the user will never see this interface due to the
revision check, they will not end up calling methods that
have been removed or renamed.
One advantage of moving to a type-erased approach for the
plumbing is that we're not longer exposing the native
interface types as part of the T::nativeInteface symbols.
This means that if we ever want to rename a native interface,
the only exported symbol that the user code relies on is
the type info. Renaming is then possible by just exporting
the type info for the old interface, but leaving it empty.
Since no class in Qt implements the old native interface,
the user will just get a nullptr back, similarly to bumping
the revision of an interface.
Change-Id: Ie50d8fb536aafe2836370caacb22afbcfaf1712a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When using native dock widgets on macOS, it will currently
fail if you try to drag on a dock widget inside QMainWindow
to make it floating. The reason is that the drag will
basically start as as drag inside one NSWindow (QMainWindow),
but continue as a drag on another NSWindow (QDockWidget).
And this is not handled well by AppKit, especially since the
NSView where the drag was started is reparented into a new
NSWindow (the floating QDockWidget) while the dragging is
ongoing. And there seems to be no practical solution to how
we can support this from the cocoa QPA plugin
This patch will therefore change the logic in QDockWidget to
simply make the dock widget floating if you drag on it, rather
than actually starting a drag (but only for the described case).
Pick-to: 6.1 5.15
Fixes: QTBUG-70137
Change-Id: Ic309ee8f419b9c14894255205867bce11dc0c414
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Set y for the EditPopupMenu from the previous correct value if select handles values are zero.
The SelectionHandle.bottom() is zero if selection handles have not yet been displayed on the screen.
Task-number: QTBUG-71900
Change-Id: I3694a8edd4f0d8f8799dbac1217a75c375038e66
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since we changed binding evaluation to be always eager, we notify and
evaluate all bindings as soon as any dependency changes. This includes
bindings which have been initially installed on a property, but which
were later removed.
With lazy evaluation, we would only notify those bindings and mark them
as dirty, which is unproblematic. With eager evalution, we attempt to
evaluate the binding, though. While that part is still fine, afterwards
we would attempt to write the new value into the property. However,
there is no property at that point, as the binding is not installed.
Instead of adding a check whether the propertydataptr is null, we skip
the reevaluation completely by removing the bindings observers - and
thus the cause for the binding function's reevaluation. As soon as the
binding is set, we reevaluate the function anyway, at which point we
also capture the observers again.
Task-number: QTBUG-89505
Change-Id: Ie1885ccd8be519fb96f6fde658275810b54f445a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Already blacklisted on the other linux versions, but is failing on
SLES now in 5.15
Pick-to: 6.1 5.15
Change-Id: I267908adf94ede51e5520aa2cb806b394fb0438e
Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The m_buttons property is meant to hold the currently pressed mouse
buttons done on the contents part of a QNSView. But m_buttons can
sometimes get out of sync with AppKit (NSEvent.pressedMouseButtons).
One way this is shown to happen is if you do a mouse press on a native
child widget (that is backed by it's own QNSView), and then convert the
widget to a top-level window before the release. In that case, the
underlying QNSView will be reparented from one NSWindow to another,
which will result in the old NSWindow getting the mouseUp call instead
of the new window. The result is that we don't update m_buttons for
the reparented QNSView, which will instead be left as "pressed".
As a result of m_buttons being stuck in a faulty state, we also refuse
to send out QEvent::NonClientAreaMouseMove events to the top-level
widget. This because QNSView thinks that it's already in a dragging
state that started on the content part of the view (and not on the
strut). As a result, it can sometimes be impossible to dock a
QDockWidget back into a QMainWindow, since we basically don't send
out any frame-drag events to Qt for the new dock window.
We can reason that if you start a mouse press on the frame strut, you
cannot at the same time have an active mouse press on the view contents.
This patch will therefore remove the buttons that we know was pressed
on the frame strut from m_buttons. This will at least (be one way to)
clear the faulty pressed state, and will let us send mouse
press/drag/release (and after that, move) frame strut events to Qt.
Pick-to: 6.1 5.15
Task-number: QTBUG-70137
Change-Id: If51e1fe57d2531b659d39de85658893dae6391e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
android.app.lib_name is used for the app's lib that contains the main()
function, *.so lib files usually have non-spaced names, thus to avoid
wrong changes done to the manifest file, it's better to throw an error
in this case.
Change-Id: I4d4f0235612b308c78fd06a77690604c5c69f8ff
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
During composition of text using an input method, incomplete characters
should not be visible at all in NoEcho mode, and should be replaced by
the password character in Password mode.
In NoEcho mode, when the cursor is always at position 0, the pre-edit cursor
should also always be at that position so that the UI doesn't give
away the length of the text entered so far.
Task-number: QTBUG-84664
Change-Id: I44a30eee3f5c6fe9fa00073b0a8ac3c333fbaa59
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This amends afd7460aff
Add new app permissions API under QCoreApplication
Which added QFuture use without protection for platforms with no
real future.
Change-Id: Iac50a71c9821255621d7582481270b2023610405
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Not 100% sure if this is a bug in tsan, but turning expected into an
atomic variable will avoid the warnings.
Change-Id: I6d6a5d58f90258d201ae3880473228638de0a215
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
There was a D missing, we want to set CMAKE_REQUIRED_LIBRARIES
Pick-to: 6.1
Change-Id: I7a76d60480ef7bff439f298fe85614d3b7e3ae88
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Newer versions of the android gradle plugin already align the apk
internally. Therefore it is not necessary to indiscriminately align
every apk. So let's first check, if it is already aligned and only
align it if necessary. This prevents possible alignment errors,
which might occur when aligning it again. If it is already aligned,
we can just copy and continue signing the apk.
Fixes: QTBUG-88989
Change-Id: If29004e372e7927c88a900dc56f490bf9bce9ec7
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We can simplify and reduce the lookup table by casting to
unicode for all printable keys.
This means that non US/ASCII keyboards will have better support.
Pick-to: 5.15
Fixes: QTBUG-84494
Change-Id: I60aa6320cf1b5d82910ed77e136246d301bfc09a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
This removes traces of QPropertyAlias which is internal API which is
a) not really working even before this change (no compatibility with
QBindableInterface due to QPropertyAlias not being derived from
QUntypedPropertyData)
b) not used anywhere
For BIC reasons, we need to keep some methods still around until Qt 7,
though.
Change-Id: I5bb4735a4c88cba275dc2cc6e29a46ca09622059
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
This takes care of the last two QSFPM properties. They were postponed
because of the tricky relation between them and some bugs in handling
the changes.
The bug was fixed in bcbbbdb2d6 and
now the behavior is well-determined: updating filter regexp does
trigger case sensitivity change and vice versa. However updating
only regexp pattern (via QString overload or setFilterFixedString
or setFilterWildcard) does not change case sensitivity.
Task-number: QTBUG-85520
Change-Id: Idc41cf817de9e6263ed65a80fa40fc8415c8c856
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
filterRegularExpression and filterCaseSensitivity
will be handled in a separate commit
Task-number: QTBUG-85520
Change-Id: I848c5c6cbe8642efa156f4f5d33467976bbf0351
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
takeItem and takeChild do not signal the change correctly to the
external world, this change fixes the problem
Fixes: QTBUG-89145
Pick-to: 6.1 5.15
Change-Id: Ib4844ace53007068a2cd62eba64df99e6e45fdc0
Reviewed-by: David Faure <david.faure@kdab.com>
Could in theory be triggered with a 0 line spanning elipsis.
Pick-to: 6.1
Change-Id: I2166ee354d2f7488e1fcddfcb8c949c8ca2452fe
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
Set clip->count to 0 unconditional not just when hasRegionClip or
hasRectClip is true.
Pick-to: 6.1
Change-Id: Ib3d1c4dc24373df3d4dbc393241226a8730bb9fc
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
When versionless targets are used, they are defined as INTERFACE
IMPORTED targets. These will sit between the executable target created
by qt6_add_executable() and the underlying Qt6::XXX module library
where the finalizers are defined. We need to recurse through the link
dependencies to ensure we pick up these finalizers. This will also
ensure we pick up finalizers in deeper targets from transitive
dependencies.
Fixes: QTBUG-93387
Change-Id: If8524ebf0e75c8790858dd7e42aa1cf4ebdfd989
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Allow collecting all public dependency CMake targets starting from
a given initial target.
The new mode walks INTERFACE_LINK_LIBRARIES of a shared library
or executable target, as well as the INTERFACE_LINK_LIBRARIES and
LINK_LIBRARIES of a static library target.
Each encountered target (checked with if(TARGET)) is added the output
list.
Note that the private dependencies of a non-static target (like a
shared library or executable) are not walked by the new mode.
Introduce a new function called
__qt_internal_collect_all_target_dependencies which uses the new
mode to collect the full private dependency list of a target.
The final list only contains targets, so no linker flags or file
paths.
This list is useful to do further processing on the targets like
extracting properties from them and running finalizers.
Task-number: QTBUG-92933
Change-Id: I5d96cfa05722d65e2248a344a4f2b0f98a992817
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Needed for the upcoming static plugin mechanism, where we have to
extract the list of Qt module dependencies of a target and then extract
the plugins associated with those modules.
To do that we need to recursively collect the dependencies of a given
target.
Rename the moved functions to contain the __qt_internal prefix.
Also rename the existing QtPublicTargetsHelpers.cmake into
QtPlatformTargetHelpers.cmake to avoid confusion with the newly
introduced QtPublicTargetHelpers.cmake.
Task-number: QTBUG-92933
Change-Id: I48b5b6a8718a3424f59ca60f11fc9e97a809765d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Extract common static plugin handling functionality into a separate
QtPublicPluginHelpers.cmake file which is loaded by the Qt6 package.
Split the code into smaller functions that will be re-used by each
templated QtPlugins.cmake.in file, rather than copy pasting the same
code into each QtFooPlugins.cmake file.
As a drive-by, handle QtFeatures.cmake and QtFeaturesCommon.cmake
as public helper files just like QtPublicPluginHelpers.cmake.
This makes it clearer that the functions are available outside
the internal Qt build and also provides a way for not dumping new
helper functions into Qt6CoreMacros.cmake.
Task-number: QTBUG-92933
Change-Id: Id816ef009b4fac1cd317d3ef23f21b3530028067
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
child->widget() returns null if the layout item is not a widget.
Thus, calling removeWidget(nullptr) will remove all non-widget items
such as layouts or strechers.
Change-Id: I772c1158d0f7e8e2850b6e571b0405a2896f09b8
Pick-to: 6.0 6.1 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
Previously, resizeMaximizedWindows() would use the device
independent screen size as the source of truth when
setting window sizes. However this size may have been
rounded, which means that e.g. a fullscreen window may
fail to cover the entire screen.
Instead, use the native screen size as the true screen
size. Set QPlatformWindow geometry, and let the
platform update QWindow geometry via geometry change
events.
Pick-to: 6.1
Fixes: QTBUG-87334
Change-Id: If6e4852dea46ab03c83e469808c0047bc933ee47
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The name made me fall in a trap: I thought that testFlag returned
true if *any* of the bits in the argument were set in the QFlags
object. In reality, it returns true if *all* the bits are set, and
an argument equivalent to 0 is treated specially. Clarify this
in the documentation.
Change-Id: I9e8088c48038b4e6ba5830fdb7e473c6d7884b29
Pick-to: 5.15 6.0 6.1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Bring back the code that was removed by
62c3dd5632 to the Windows theme.
Pick-to: 6.1
Fixes: QTBUG-93635
Change-Id: I066e89d482a584c1719f6bfb6160710ee73e1b81
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
It's a value type, and we don't need detours through implicit
conversions (which are a real disgrace, as they make nonsense like
`flags != 3.14` well-formed).
[ChangeLog][QtCore][QFlags] Added overloads of operator== and
operator!= between QFlags objects, and between a QFlags object
and an object of the flag's enumeration.
Change-Id: I36701dea8fcd4cc64941e78af58fa7d38a15a8c7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Now that we run tests for static Qt builds in the CI, it makes sense
to restore the CMake build tests that check that static plugin
importing works correctly.
Resurrect the previously commented out test_import_plugins project and
port the mockplugins qmake projects to CMake.
mockplugins is a CMake project that uses the internal Qt CMake API to
build and install some Qt modules and plugins.
test_import_plugins depends on that test (via a CMake fixture) to
build public projects that use those plugins.
The installation of the mockplugins modules pollutes the Qt install
prefix, but in the CI that only happens on the test VM, which means
the release packages are not affected.
Locally on a developer machine the Qt install path will be polluted,
but it's not that much of a big deal. We could try and address that in
a future change by using the QT_ADDITIONAL_PACKAGES_PREFIX_PATH
functionality added for Conan to allow the installation of Qt packages
into a non-standard prefix.
Task-number: QTBUG-87580
Task-number: QTBUG-92933
Change-Id: I0841064a60a5ffba5118640d3197527a38ba6c30
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
The Qt CMake packages are not installed yet, so the CMake build
projects can't find Qt and fail to configure.
Skip the CMake build tests in a prefix in-tree configuration and issue
a warning for informational purposes.
Change-Id: Ie5cb5b9f6f1d8ec258b70528680e31c711c20f85
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Although Qt 6 supports API 23+, it's still not bad to do this fix, it
achieves two things:
* Avoid the use of reflection when checking for permission state
* It works for all api versions
With this we would be sure we don't need to do a check in c++
if (androidSdkVersion < 23)
return true;
The platform api checks if permission is granted or not, irrelevant of
the api version.
Change-Id: I9766dc35bbc8347ad0d60fde54b95710c8866736
Reviewed-by: Alex Blasche <alexander.blasche@qt.io>
When the listview setWordWrap is true and ScrollBarPolicy is
ScrollBarAsNeeded, if the text needs a newline display and the
vbar is not shown, the width of the item was subtracted from
the width of the scrollbar.
In most cases, the listview needs to reserve the size of the scrollbar.
But if the flow is TopToBottom and the vertical scrollbar is not
visible, the width of the vertical scrollbar cannot be reserved.
Fixes: QTBUG-92366
Pick-to: 5.15 6.0 6.1
Change-Id: I73cce691099a253d409019dbb3fe9a16e1830bb1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Bitwise ANDing an enum and a QFlags should yield identical results
as ANDing a QFlags and the enum. This latter operator already existed,
so add support for the former.
Plus, ANDing two enumerators of a flag type should yield a QFlags, and
not a plain int. (Note that an arbitrary amount of bits can be set
in the result of such operation, as the enumerators themselves may be
masks with more than 1 bit set.)
This is slightly source incompatible, as we're changing the return
type of operator&. Code that was assigning that result to `int` still
works as expected, but code that wanted the value back in a QFlags may
have inserted some conversions like:
flag = Enum(enumerator & otherFlag);
^---------------------
used to yield int, now QFlags
which are now going to break as there's no QFlags->Enum conversion.
An earlier attempt of this patch, introduced -- and immediately
deprecated -- such a conversion, under the form of
explicit operator Enum() const;
in order to keep such old code working both before and after this
change. The problem is that MSVC has a bug with explicit conversions to
enumerations [1], which get accidentally considered when they shouldn't,
and thus making a lot of code stop compiling due to (false) ambiguities.
So, I'm not adding that operator any more.
Note that there's a way to keep code working before and after this
change: just use
flag = Flags(enumerator & otherFlag); // Flags, not Enum
(thanks Edward), which goes through a int -> QFlag -> QFlags conversion,
and arguably is the idiomatic way of writing such code; or use
flag = otherFlag & enumerator;
which, as discussed above, has always returned a QFlags.
[1] https://developercommunity2.visualstudio.com/t/explicit-conversion-operator-to-enum-is/1412616
[ChangeLog][Potentially Source-Incompatible Changes][QFlags] Bitwise
AND-ing two values of an enum type for which flag operations have been
declared now produces a QFlags object. Similarly, AND-ing a value
of enum type and one of type QFlags now produces a QFlags object.
Before, it produced an integer in both cases. This may introduce a
slight incompatibility in user code; it is possible to keep the code
working in Qt versions before and after this change by inserting
enough conversions to QFlags, and/or by changing expressions such as
`enum & flag` to `flag & enum` (the latter has always produced a QFlags
object).
Change-Id: I6e645c010d3aa677820545b0c25678f1dc9a3295
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It makes no sense to offer the "type-unsafe" operators taking a plain
int, and not offer the ones taking a QFlags object. Using these
operators has actually always worked by going through a conversion to
int, but we're going to limit that possibility in the future.
[ChangeLog][QtCore][QFlags] The operator& and operator&= now accept
a QFlags object.
Change-Id: Iee0845640014d35b646787e8bdb77854f180a9ef
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Stop going through the implicit int conversion.
[ChangeLog][QtCore][QFlags] QFlags now has a qHash() overload.
Change-Id: Id380ed252695f24af2e8c239b650dcb6f44e2893
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There are some use cases where one may want to convert a QFlags object
from/to an integer deliberately; for instance, to store it in a
bitfield, saving some space. So far this worked by means of a implicit
conversions; instead, also add named conversions for this.
[ChangeLog][QtCore][QFlags] Added the fromInt() and toInt() functions
for explicit conversions from/to a plain integer.
Change-Id: I705559bf75b28c30b4446bb6d0753aedfc808eed
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since Windows can synthesize certain font traits for us, we
used to register these in the font database so that we could
match against them. But after change
469b139169, this in principle
no longer happens, because we opt out whenever there is a
style name (which there usually is, this could be e.g.
"Regular" for a normal font). The result of this was that
if we looked for a bold variant of a font, we would not find
it.
In cases where a multi-engine was used, the request for bold
would still survive in the multi engine's fontDef, so we would
still pick it up later and apply the synthesis. But when
NoFontMerging was set, then we would override the weight in
the fontDef with the one from the font database.
Since the comment documents that the additional registrations
are there to make sure all the variants that Windows can
synthesize are available for matching, it does not make sense
to skip them just because the font has a style name. So this
is a partial revert of 469b139169.
Note: This exposed an error in QFontDatabase::isSmoothlyScalable().
The style parameter here is not the "styleName" (as in sub-family),
but actually predates that API. Instead it is the "style" as
returned by QFontDatabase::styles(), which may be the style
name, but it can also be the generated description of the style
and weight. In the latter case, we would return false for fonts
that are actually smoothly scalable, which is incorrect. This
caused a failure in tst_QFontMetrics::metrics(). To remedy this,
we add an additional condition, and also match the style if it
matches the generated descripion of the style key.
[ChangeLog][Windows] Fixed an issue where bold/italic would not
be synthesized for fonts if QFont::NoFontMerging was set.
Pick-to: 5.15 6.1
Fixes: QTBUG-91398
Change-Id: Id2166a47ae2d386536cf6e5e27ff09165ae8a23a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
The functions are available as private API though
qt_mac_addToGlobalMimeList and qt_mac_removeFromGlobalMimeList for
those that need it.
Task-number: QTBUG-83252
Change-Id: Ibc17aedd9aaced236a082d3d8de4b28313406a02
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
This was probably introduced for Symbian and did not change since
the Qt4 import (except for the Symbian code cleanup). Since it seems
only to effect Windows, use Q_OS_WIN instead.
Change-Id: I36f4d83ed5254d8b77073fc216551dfa0cc64a9f
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The commit amends commit 3966b571 to take UNC prefix into account as
well. Fixes the weird file name output as reported in QTBUG-74291 and
QTBUG-83365. Replace manual separator normalizing in qt_cleanPath(),
this is another spot where UNC prefix handling needs to be applied.
Also make QTemporaryFile operate on '/' as file separators to fix
creating both file types with native path separators on network shares.
Fixes: QTBUG-74291
Fixes: QTBUG-76228
Fixes: QTBUG-83365
Pick-to: 5.15 6.0 6.1
Change-Id: Iff8d26b994bf4194c074cd5c996cda3934297fa5
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
