When the marked text was not an attributed string with built in styling
we used to fall back to a hard-coded underline style.
We now pick up the default marked text style via the markedTextAttributes
property of a temporarily created NSView, which by default is a yellow
background color.
The implementation in NSView respects text system configuration toggles
such as NSMarkedTextAttribute and NSMarkedTextColor, so by setting the
user default NSMarkedTextAttribute to "Underline" the marked text will
look like our old hard-coded default. This can be done in many ways,
including passing `-NSMarkedTextAttribute Underline` on the command
line, or by QSettings::setValue("NSMarkedTextAttribute", "Underline");
Pick-to: 6.2
Change-Id: Iede74836ed1449e77018c13733a675f8e9d84f7d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The logic was not taking into account that we were always adding
an QInputMethodEvent::Cursor attribute, so we would never hit the
fallback code.
Pick-to: 6.2
Change-Id: I25bd725025152241a55e3fea60444c20e27db4f9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We don't need to condition this on IM enablement. The attributes are
only used if we are actually marking text, which only happens for IM
enabled views.
Pick-to: 6.2
Change-Id: I47377cf53cf2bf44a1d9513d317f82c73f083fa3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
URLs can contain underscores, not "undercores".
Pick-to: 6.2
Change-Id: I000ed89649cee0e7c6f283f2d930097961379445
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The incorrect "scoping" of q_IOObjectRetain and q_IOObjectRelease
luckily did not affect their functionality as QIOType helpers.
Pick-to: 6.2
Change-Id: I9b9c2312464c7e6f8e2d2a5856e35efa99ec0c41
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When forcing software scrolling through QScroller::scrollTo,
it will start from (0, 0). QGraphicsViewPrivate::canStartScrollingAt
should consider the locationof points, not just the flags of item.
Fixes: QTBUG-70255
Pick-to: 5.15 6.1 6.2
Change-Id: Iebdd5568baa3bdb41c705204dadb2895cfe9c0e2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The standard palette had no value set for ButtonText. The
result was the we drew button text in QtQuickControls2
using Text color instead, which would be wrong in dark
mode, and result in a dark color instead of white.
Note: Widgets hardcode the color "white" directly
in the mac style, and was not affected by the
missing value.
Fixes: QTBUG-89177
Pick-to: 6.2 6.1
Change-Id: Ie2d99bfac9fcc70d45e5bd40ea45becf3fd70d87
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
SetProcessDpiAwarenessContext() returns ERROR_ACCESS_DENIED if the
DPI awareness has already been set, and not E_ACCESSDENIED like
SetProcessDpiAwareness() does.
Pick-to: 6.2
Change-Id: I6b29214773776f31c0622a35494d98c5c9637b0b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
On macOS, we close active popups when handling mouse-down events in the
NSView, but not for such events in the window frame. This allows users
to close a window that has a context menu open via the window's close
button, which then leaves open popups behind.
Factor the popup-closing code out into a dedicated method that we can
call from within the NSWindow::sendEvent implementation for mouse down
events.
Fixes: QTBUG-30522
Pick-to: 6.2 6.1 5.15
Change-Id: I9c354efc449cfefff3ed84fa34b1cd8a0da3b4a7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
For better overview of the flow and functionality of the
NSTextInputClient protocol.
Pick-to: 6.2
Change-Id: I8658405c7ff4ae762bfe3e4c11f9a157ae2b9a09
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Instead of going via QNSView. Also add some logging.
Pick-to: 6.2
Change-Id: Iabed7511572ef22597651efa8047f06227b28533
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
After enabling -s MODULARIZE=1 there is no longer a
global ENV. Use module.ENV instead.
Change-Id: Ic6958f52c6ceb7014f7f2c78a73f2bce5a43bf41
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Previously, this was implemented in QEventLoop. By moving
it to the event dispatcher we can target the warning message
better and provide a suggested workaround for the dialog
case.
The behavior is the same as before: call emscripten_sleep(),
which throws a Javascript exception and returns control
to the browser while leaking the content of the stack.
Pick-to: 6.2
Change-Id: I2979fe4fe5923c27713e85b6725614b60a693e93
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
like windows, we dont have historical time data
Change-Id: Iab77c1e2949bc909324f18209e6c52324c80a548
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This patch is inspired by CodeChecker, that is complaining about
possible nullptr dereferencing.
Currently it is a false-positive, because the codepath suggested by
CodeChecker is impossible with current implementation.
But having asserts can save some time in case of possible refactoring.
Task-number: QTBUG-95727
Pick-to: 6.2
Change-Id: I242a23e8aaa249cce16b867c0884dfc3849977f5
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
Installing extracted metatypes json files for user projects was an
oversight. We shouldn't install anything on behalf of user projects,
but rather give them enough information so they can do it the
themselves.
Make all the install options of qt6_extract_metatypes internal,
change the behavior not to install the files by default, unless
__QT_INTERNAL_INSTALL is passed, which is used for the Qt build only.
__QT_INTERNAL_NO_INSTALL is now a no-op and should be removed from
projects.
This is behavior change for existing public API, but it's better to
fix this now before 6.2.0 release.
Introduce a new OUTPUT_FILES option to allow assigning the extracted
metatype file paths into a variable that the project provides.
The project can then install the files where they need them.
[ChangeLog][CMake] qt6_extract_metatypes does not install metatypes
files anymore. Instead the OUTPUT_FILES option can be provided to get
the list of extracted files for further processing.
Pick-to: 6.2
Task-number: QTBUG-95845
Change-Id: If5dd0255a5fea2b598e15118c29ec2ab2ba4324e
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
There's no need of duplicating code all over the place; QString can
reuse the implementation of the indexOf/contains/count/lastIndexOf
family of functions already existing for QStringView.
For simplicity, the warning messages (that our autotests actually check)
have been made more generic, rather than introducing some other
parameter (as in, "which class is using this functionality so to emit
a more precise warning"), which would have just complicated things as
the implementation of these functions is exported and used by inline
QStringView member functions.
Change-Id: I85cd94a31c82b00d61341b3058b954749a2d6c6b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
An empty QString(View) is allowed to have nullptr as its data pointer
(of course, only if its size is 0). This wasn't properly
checked in QRegularExpression, which passed such nullptr to
PCRE, and that resulted in PCRE raising an error (PCRE_ERROR_NULL).
Detect this case and pass a dummy pointer to keep PCRE happy.
Fixing and testing this in turn exposed a problem with QStringView
support in QRegularExpression when used over a null QString: the
code is supposed to use the QStringView(QString) constructor and NOT
qToStringViewIgnoringNull. That's because QRE distinguishes null
and empty subjects; when using qToStringViewIgnoringNull over
a null QString, one gets a non-null QStringView (!). Again, this in
turn exposed a problem with a QRegularExpression autotest that assumed
that a null match could only mean "no match" (instead, it can happen at
position 0 of a null QString(View)).
Change-Id: Ifb3cf14dec42ce76fcdbcb07ea1d80784d52ef65
Pick-to: 6.1 6.2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@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>
When trying to fix 0-length matches at the end of a QString,
be83ff65c4 actually introduced a
regression due to how lastIndexOf interprets its `from` parameter.
The "established" (=legacy) interpretation of a negative `from` is that
it is supposed to indicate that we want the last match at offset `from +
size()`. With the default from of -1, that means we want a match
starting at most at position `size() - 1` inclusive, i.e. *at* the last
position in the string. The aforementioned commit changed that, by
allowing a match at position `size()` instead, and this behavioral
change broke code.
The problem the commit tried to fix was that empty matches *are* allowed
to happen at position size(): the last match of regexp // inside the
string "test" is indeed at position 4 (the regexp matches 5 times).
Changing the meaning of negative from to include that last position (in
general: to include position `from+size()+1` as the last valid matching
position, in case of a negative `from`) has unfortunately broken client
code. Therefore, we need to revert it. This patch does that, adapting
the tests as necessary (drive-by: a broken #undef is removed).
Reverting the patch however is not sufficient. What we are facing here
is an historical API mistake that forces the default `from` (-1) to
*skip* the truly last possible match; the mistake is that thre is simply
no way to pass a negative `from` and obtain that match. This means that
the revert will now cause code like this:
str.lastIndexOf(QRE("")); // `from` defaulted to -1
NOT to return str.size(), which is counter-intuitive and wrong. Other
APIs expose this inconsistency: for instance, using
QRegularExpressionIterator would actually yield a last match at position
str.size(). Similarly, using QString::count would return `str.size()+1`.
Note that, in general, it's still possible for clients to call
str.lastIndexOf(~~~, str.size())
to get the "truly last" match.
This patch also tries to fix this case ("have our cake and eat it").
First and foremost, a couple of bugs in QByteArray and QString code are
fixed (when dealing with 0-length needles).
Second, a lastIndexOf overload is added. One overload is the "legacy"
one, that will honor the pre-existing semantics of negative `from`. The
new overload does NOT take a `from` parameter at all, and will actually
match from the truly end (by simply calling `lastIndexOf(~~~, size())`
internally).
These overloads are offered for all the existing lastIndexOf()
overloads, not only the ones taking QRE.
This means that code simply using `lastIndexOf` without any `from`
parameter get the "correct" behavior for 0-length matches, and code that
specifies one gets the legacy behavior. Matches of length > 0 are not
affected anyways, as they can't match at position size().
[ChangeLog][Important Behavior Changes] A regression in the behavior of
the lastIndexOf() function on text-related containers and views
(QString, QStringView, QByteArray, QByteArrayView, QLatin1String) has
been fixed, and the behavior made consistent and more in line with
user expectations. When lastIndexOf() is invoked with a negative `from`
position, the last match has now to start at the last character in the
container/view (before, it was at the position *past* the last
character). This makes a difference when using lastIndexOf() with a
needle that has 0 length (for instance an empty string, a regular
expression that can match 0 characters, and so on); any other case is
unaffected. To retrieve the "truly last" match, one can pass a
positive `from` offset to lastIndexOf() (basically, pass `size()` as the
`from` parameter). To make calls such as `text.lastIndexOf(~~~);`, that
do not pass any `from` parameter, behave properly, a new lastIndexOf()
overload has been added to all the text containers/views. This overload
does not take a `from` parameter at all, and will search starting from
one character past the end of the text, therefore returning a correct
result when used with needles that may yield 0-length matches. Client
code may need to be recompiled in order to use this new overload.
Conversely, client code that needs to skip the "truly last" match now
needs to pass -1 as the `from` parameter instead of relying on the
default.
Change-Id: I5e92bdcf1a57c2c3cca97b6adccf0883d00a92e5
Fixes: QTBUG-94215
Pick-to: 6.2
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This is a no-op. But take the opportunity to make a drive-by update on
the loop, which improves it.
Change-Id: I4a40ccbd3321467a8429fffd169b08590d28c928
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
We already do it for inputs but weren't doing it for outputs.
Change-Id: I4a40ccbd3321467a8429fffd169afeb5730ad75e
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Wrap the overloaded methods in qOverload(), to make the examples
compile.
Also remove the extra whitespaces when declaring nested templates.
Pick-to: 6.1 6.2
Change-Id: If438caa6d705d9036dae45278fb26e080918da89
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The code isn't easily linearized to work directly with
QStringTokenizer, which is a forward-only range, but we can at least
remove the (non-error) memory allocations by supplying a
suitably-sized QVLA to tokenize into instead of the default QList.
Change-Id: I1aa11a5fbbe66ede4ec2e5b2090044a39052a241
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>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
By dropping the clause pointlessly guarding the ranged for loop against
an empty collection, we can reduce the ping-pong being played with the
*ok boolean: Just set it to false at the beginning, and only set it to
true when we reach the success-return.
Pick-to: 6.2
Change-Id: I87365146086aba427b7414e83f077096824ff56f
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The variable `i` is initially `suffixPos + 1` and is then incremented
further. It therefore can never be equal to `suffixPos` (ints don't
overflow, that would be UB, and suffixPos doesn't change its value),
so don't check for that.
Change-Id: I3870ddf6ee550cad6c24fececf2a0b662a33d750
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The wasm support files need to be both copied and installed in a
top-level prefix build, to ensure that leaf repos can find them in the
build dir when they are configured.
Pick-to: 6.2
Fixes: QTBUG-95806
Change-Id: I8c09f04fec51cf850299d535bdf3f26542ec4aac
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
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>
Some internal links to `QSet` methods were missing from the
documentation. In particular, all methods that were written with one
attribute.
It seems that QDoc might automatically recognize method/function
links only if they have zero parameters, such that the identifier is
followed by `()` directly.
To avoid this problem while keeping the current parameter-containing
form of the text; each function of the form `functioname(\a
parametername)` was changed to `\l {functionname()} {functioname(\a
parametername)}.
Furthermore, one of those text instances was modified to use `\a` for
the parameter name, instead of the previously used `\e`, to enhance
consistency.
An instance of `operator<<()` was not recognized as a link.
To resolve this it was marked with the `\l` command.
Fixes: QTBUG-95389
Pick-to: 6.2 6.1
Change-Id: I16b2a7a2fbaf4785c2c6bfa5017a3db46d9db2f4
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
ImAbsolutePosition was added in f8dbed1226,
based on requirements on Android, but without an implementation for
QLineEdit. It would seem sensible to fall back to the cursor position
in this case, as QLineEdit doesn't support multiple blocks.
Pick-to: 6.2
Change-Id: Iff1255270ceef069f03ce457df633d7b675f1a28
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends 359616066e, which incorrectly
changed
- tabList[i].minRect = QRect(0, miny, sz.width(), sz.height());
+ tab->data = QRect(0, miny, sz.width(), sz.height());
in the code laying out verticals tabs (correct done for the horizontal
case).
Since QDockWidget uses the user data for tabs to maintain the mapping
between tabs and dock widget, this broke the layout logic.
Fixes: QTBUG-95841
Pick-to: 6.2 6.1
Change-Id: Ie785e1205b426bbc4954b965f619f4c603490f76
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The QtConcurrent::RunFunctionTask class keeps a variable to store the
result of QtConcurrent::run when it becomes available, so that it can be
reported afterwards. This requires the result type to be
default-constructible. However there's no need in storing the result, it
can be reported immediately after it becomes available.
Pick-to: 6.1 6.2
Fixes: QTBUG-95214
Change-Id: I95f3dbff0ab41eaa81b104a8834b37d10a0d193a
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Add see also link from operator== and operator!=
to matches() to avoid possible confusion.
Fixes: QTBUG-95820
Pick-to: 6.2 5.15
Change-Id: Ica8112da436b57da0d410f8e1f6b71fc6bf0791f
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
This avoids rebuilding the same pattern. Caught by clazy.
Change-Id: Ibd0f2063617df1a9e975f58e34df556d1983afff
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
