Generally isValid should be called by the bridge, but in this case, we
must verify the validity internally since we derefernce the interface
internally.
Task-number: QTBUG-52536
Change-Id: I14950118e58d65135bc38d77c23b8a7fed8bf39a
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
The style name needs to be cleared if not present in the string,
otherwise the style name from qApp->font() (which propagates to
any default-constructed QFont) remains.
Change-Id: I9b6522a39a38526cced8a11ed02ae32582026480
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Konstantin Shegunov <kshegunov@gmail.com>
The test failed if qApp->font() had a styleName() set,
when testing old serialization formats which didn't serialize it.
Change-Id: If0236d354be144b3a990e074a22f796fffb1ed18
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Reviewed-by: Konstantin Shegunov <kshegunov@gmail.com>
When generating the Visual Studio project XML, the filter "Root Files"
was not being output. Specifically, this means that even if RC_FILE was
specified, it would not be included properly as a resource compilation
target in the resultant Visual Studio project file.
This is essentially a rather belated cherry-pick of qt/d6de960b7f.
Task-number: QTBUG-57914
Change-Id: I7d03dc818df0cf36608012f1a71a3a476d8a9ff7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Because of QRect's width and height are caluculated values, they got
spoiled after x and y values setting.
This bug affects, in particular, Android software keyboard appearance:
it could overlap focused input field.
Change-Id: I27ccca27111219818722951fe6f463388d76c702
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: BogDan Vatra <bogdan@kdab.com>
Qt doesn't create the actual QDockWidgets when restoring, the user must
ensure they are created before restoring state. So lets not create an empty
QDockWidgetGroupWindow which you can't close and with no tabs.
Change-Id: If0a6aa7cf6f3932ff4274e03f787e27aef8fa53d
Task-Id: QTBUG-57492
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
There are some keyboard layouts where pressing shift will give something
different to what the expected key would be. For example, on a French
keyboard layout, pressing SHIFT+! gives 1 as opposed to SHIFT+1 giving
! on a US keyboard layout. Therefore it should check against both cases
to ensure it does not end up adding a new entry.
Task-number: QTBUG-57938
Change-Id: I11c52619c048b98500f2d79876bb912720af6e65
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Use the scaling factor when calculating the initial size of the
platform window.
Change-Id: Ie21f0da14e32ac437efbc304a3fd9722a7f8615e
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The population of data rows was factored into a separate file, qutf8data.cpp, in
commit e20c4730. Merge commit 9bd03235 failed to track a conflicting change into
the new file, and brought the code back into the tst_utf8.cpp, where it has been
duplicating the utf8data data ever since.
Change-Id: I4282685b882448f927289468bd7ab340a21ea0b3
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For language "Traditional Chinese" on iOS with region "US",
the logic was formerly to attempt a match on country/language/script (fail),
followed by country/language (which would result in script defaulting to
"Simplified"). Now, the logic is to try language/script first if script is
specified. Failing that, language/country will be attempted.
Task-number: QTBUG-39639
Change-Id: I75a774b1e66686e95167ff221458a97a7ea2660d
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Jason Erb <jason.erb@sparist.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If we use QLatin1String we should include qstring.h.
Change-Id: Iebd761b98e515e9cd9cd34b96a0f8a602d00f086
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The future tests don't need QtConcurrent as QFuture and friends are in
QtCore. The printdevice test doesn't use QtNetwork and the lancelot as
well as the testlib tests don't use QtXml.
Change-Id: I150ac99b36682aa23ad22ba943266eb0f0952838
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
When a keyboard is using an input method then the layout for it needs to
be retrieved with TISCopyInputMethodKeyboardLayoutOverride(). For cases
where it is not using an input method this will return null and in that
case we can use the original approach as before.
Task-number: QTBUG-53804
Task-number: QTBUG-57934
Change-Id: I6283785bf002602113e208bb38d5eb2a9a7ceb36
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The unknown types are treated as strings by default.
Coverity-Id: 59489
Change-Id: Ib0eaf5c27d3afaf694c8a2acca42bef6808c8a9f
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
An internal, private symbol was changed in
beef975f92. However, this symbol was being
used by some inline functions in QtTest, and this therefore introduced a
BIC. This change simple adds back a symbol with the original signature.
I recall seeing this in my own work, and the KDE CI system hits this as
well:
libKF5KDELibs4Support.so.5.25.0: undefined reference to
`qt_handleMouseEvent(QWindow*, QPointF const&, QPointF const&,
QFlags<Qt::MouseButton>, QFlags<Qt::KeyboardModifier>)'
Task-number: QTBUG-52205
Change-Id: I4e85996850cc436b6a31addca3a8f9829c0c5edd
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
for some inexplicable reason, configure.bat went into an endless loop
on win 8.1+ while attempting to parse the command line; this is clearly
a bug in cmd, so work around it.
amends 7af6e9bb.
Task-number: QTBUG-58019
Change-Id: I698a2a51891a4e7af75836c075888f70df865409
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
activated() is actually triggered(), highlighted() is actually hovered()
Task-number: QTBUG-50315
Change-Id: Ieefdc8376102d80d0885a6c7ca47a9380945afef
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
Don't use Dinkum choices when the C++ library is libC++ (QNX 7.0).
Change-Id: I18c3f716ccfb0c02dbfdc01eac4b707d3ae9aab6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
qundostack.cpp: Command '\li' outside of '\list' and '\table'
Change-Id: Ic162e246c754e125f6ae82a2a66312e925b231c2
Reviewed-by: Martin Smith <martin.smith@qt.io>
StripTrailingSlash removes trailing slashes from the path, but not the
entire URL.
Task-number: QTBUG-47607
Change-Id: Id62b971e563e290b7ca000576bcc328616a3f1a2
Reviewed-by: David Faure <david.faure@kdab.com>
When qreal is float, it cannot represent all values an int can take,
so we may lose precision in the expression
qreal(a) / b
as opposed to the double result
double(a) / b
For lack of trying, I do not know of a value where this would change
the resulting 'fillWidth' value, but better be safe than sorry, and
use double instead of qreal arithmetic.
Also, when calculating fillRatio, we were converting values back and
forth between qreal and double. Using double everywhere avoids that.
Found while reviewing integer arithmetic in QProgressBar as part of
the fix for QTBUG-57857.
Change-Id: I054cb11d35e3ecf5bf79b5c8ee39029bd23bcf49
Reviewed-by: David Faure <david.faure@kdab.com>
When qreal is float, it cannot represent all values an int can take,
so we may lose precision in the expression
qreal(value) - minimum
as opposed to the exact result
qint64(value) - minimum'
For lack of trying, I do not know of a value where this would change
the resulting 'progressBarWidth' value, but better be safe than sorry,
and use the 64-bit integer expression instead of floating-point.
Found while reviewing integer arithmetic in QProgressBar as part of
the fix for QTBUG-57857.
Change-Id: I0240c143bb75af6986910489b34042ce9b3a8caa
Reviewed-by: David Faure <david.faure@kdab.com>
There were some strange sentences that did not add to the documentation
of HSL vs. HSV.
Task-number: QTBUG-52483
Change-Id: I5f2b8c3bd420fe9cabc74a94af4b78945723b6cf
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The arithmetic used to calculate the size of the progress bar fill in
QPixmapStyle assumed minimum == 0, but that does not necessarily
hold, since the minimum value is user-defined.
So, fix the arithmetic to take the minimum into account, taking care,
as done elsewhere, to avoid signed integer and qreal=float overflows,
by using qint64 and double, respectively.
[ChangeLog][QtWidgets][QPixmapStyle] Now handles progress bars with
minimum != 0 correctly.
Change-Id: I738ded56e8234716c36a5e9fde15bae691c43a35
Reviewed-by: David Faure <david.faure@kdab.com>
When qreal is float, it cannot represent all values an int can take,
so we may lose precision in the expression
qreal(d->value) - d->minimum
as opposed to the exact result
qint64(d->value) - d->minimum'
For lack of trying, I do not know of a value where this would change
the resulting 'progress' value, but better be safe than sorry, and use
the 64-bit integer expression instead.
Found while reviewing integer arithmetic in QProgressBar as part of
the fix for QTBUG-57857.
While touching the line, make the (intended) double → int truncation
explicit, by using a static_cast.
Change-Id: I03dbfce24c709310c3bbad9487a2bf0d1d78137a
Reviewed-by: David Faure <david.faure@kdab.com>
The expression '100' already has type int, so the cast is not necessary,
and confusing.
Remove it.
Change-Id: Id63f56645b1b13532f73e481547c2a606dfc9c9a
Reviewed-by: David Faure <david.faure@kdab.com>
the second dash would end up in the option name, which made it obviously
unrecognizable.
but the second dash isn't optional in the first place (as evidenced one
line up), so remove the question marks.
Task-number: QTBUG-57908
Change-Id: I6622fef7d11d7b3c485f16698349d1912037a41e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
plugins may pull in additional qt modules which may require additional
plugins in turn.
Change-Id: I22264b39c1397666b2dc9079048ed1fc64aa84d9
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
while we already linked the plugins for our own private deps, we failed
to do so for our transitive deps.
this also fixes linking qml plugins if qml is linked only indirectly and
privately.
the code for setting up rpath-link is slightly refactored as a side
effect, with no functional change.
the code for setting up rpath now also sees the longer list of
dependencies, but that's irrelevant, as qtcore always ends up among the
direct deps anyway iff any non-bootstrapped modules are used.
Change-Id: I90dca81a2836c6191ce5d092e16bf7660ee820bc
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
static plugins must be actually linked into the target whenever it is
not a static library itself.
apart from fixing qml plugin linkage, this also provides a more generic
fix for the already fixed linking of activeqt controls.
Task-number: QTBUG-28215
Task-number: QTBUG-55279
Change-Id: I9661369bf3dfc6bcf3a5ed563e6716eb3ef6e76e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... instead of the directory it resides in, to make it independent of
the user's fs layout. this makes logs more comparable, and little else.
Change-Id: I0ab3e968dad74ef86577f388c8ca1557e3c17ce4
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this was introduced in 60e5a1c8 for no apparent reason.
Change-Id: Idcbc6df3df4e4846c76b3e4215d753a1c97e2eec
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the arguments after '--' are by definition meant only for the top-level
project, as that's where configure is invoked from. passing them to
sub-projects just adds noise to the make output and misleads users.
note that this specifically does not support qmake -r, which will break
if the subprojects rely on the arguments being absent. this isn't a
problem, because the qt build doesn't support qmake -r anyway.
Change-Id: I7ecff6212ce3137526005fc324a4a7ae45e3345e
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
turns out that just appending builtin-qt.conf isn't a good idea:
executable-editing tools (objcopy, prelink, etc.) will happily drop the
"attachment".
a safe method would be adding a proper section to the executable, but
there doesn't appear to be an objcopy equivalent in msvc, and using
entirely different methods of embedding the file with different
toolchains seems like a rather bad idea.
so instead go back to the old method of building qmake with a generated
qconfig.cpp. of course, as said file is now created by qmake itself, we
have to compile qlibraryinfo.cpp a second time, and link a second qmake
executable.
Task-number: QTBUG-57803
Change-Id: I9e232693550aa870cec154e49cc06add13017cc2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
it makes the call more noisy for no particular reason.
and the new code is even easier to read ...
Change-Id: Ib4dfd373f351eeaca99e6bfc42b631f931ec987d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
now qmake is the last command called by the unix configure script.
as it happens, this was already the case in the windows script, but only
because it didn't print these messages at all, which it implicitly does
now.
another effect of this is that repositories outside qtbase will now also
get the installation note in modular builds, which makes sense.
Change-Id: I567146936b216185a8e0f61e445222215608bf13
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Commit 824f08046 introduced QPlatformSystemTrayIcon::createMenu() as a way
for platforms to provide a system tray menu independently of the menu
created by QPlatformTheme::createPlatformMenu(), which would on some
platforms be null.
Commit 063997f44f then made menu creation lazy, which meant that the
logic in QSystemTrayIconPrivate::addPlatformMenu() to create the menu
turned from "create menu via QPSTI::createMenu() if QPT::createPlatformMenu()
returned null", to "create menu via QPSTI::createMenu() if menu was not
created yet". The latter logic relied on each platform having implementations
of QPlatformSystemTrayIcon::createMenu() which they didn't, resulting in
missing menus for system trays on e.g. macOS.
With the new lazy logic, the reasonable approach is for the default
implementation of createMenu() to use createPlatformMenu(), which will
ensure system tray menus on platforms that implement createPlatformMenu(),
while still allowing platforms that don't to override createMenu() for
special-casing system tray menus.
Task-number: QTBUG-57365
Change-Id: Id393e802ac0435200fc885a7f4436b744962f27f
Reviewed-by: J-P Nurmi <jpnurmi@qt.io>
... so that we can turn it off if we don't want to build it.
Change-Id: Ia330dfa1477bcd2dc8e24eb55400e100fca156b5
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
... so that we can turn it off if we don't want to build it.
Change-Id: Ib27386da4754d843d4e4cbb05f9542852efefb88
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>