These algorithms never call mid() with funky values, so they don't
need the mid() side-cases, and associated 7-branch deep conditionals.
Just use sliced().
Change-Id: I05b6a0e47da90f09b34a92211f7e783a2db709f7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also, add a TODO for migrating to QmlImportsPath in qt.conf.
Task-number: QTBUG-98335
Change-Id: I3c321c99c6286ba64eef643876f5b56d5a8ca695
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In case the class doens't have a default constructor, checking for
object.isValid() will give false because the object won't be created,
however, the class could still be loaded and we could have a valid
jclass.
Pick-to: 6.2
Fixes: QTBUG-96069
Change-Id: I8d59e26d9d7c0e8e363ce443937091a374a24473
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
This lets it avoid a two-digit year that would clash with month or day.
That shall make fixing up system locale date formatting run cleaner.
Add a test for QGregorianCalendar's two extensions.
Change-Id: I77083ff9d5e4035763250904a59fcf416286545b
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In paintAndFlush, QWidgetRepaintManager subtracts opaque children if
the target isn't overlapped and isMoved is set to true. So in moveRect,
set isMoved to true after the blitting of movable areas, and reset it to
false if we have overlapped sibling or child regions. Otherwise, moving
so far that sourceRect is invalid (none of the original pixels are
visible after the move) we end up in a code path that sets isMoved to
true even with overlapping children or siblings, which then breaks
paintAndFlush's assumptions.
Reuse the test case written by Sergiy Korobov <tiamatenko@gmail.com> in
earlier attempts to fix this bug.
Fixes: QTBUG-26269
Pick-to: 6.2
Change-Id: If7443863f5eee79a80220cd587522122f42a21e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
They map to the data exposed by libinput exactly the same way as
touchpad gestures on Wayland. The implementation is functionally the
same and follows the same patterns to preserve similar behavior across
X11 and Wayland.
For example, we use the last known pointer position as the position for
gestures, even though on X11 this data is available as part of events.
The new implementation is only enabled if the used xcb supports the
required APIs.
[ChangeLog][Platform Specific Changes][X11] Touchpads can now detect
multi-finger gestures and send RotateNativeGesture, ZoomNativeGesture
and PanNativeGesture events, since XInput 2.4 and X Server 21.1.
Change-Id: If404dcf8385210deadeb7e7c6d29171e9abc9e50
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Since QMainWindow::setMenuWidget accepts a QWidget (allowing users to
implement their own menu widget), we need to use qobject_cast on the
stored widget to see if it is a QMenuBar before calling QMenuBar APIs.
This qobject_cast may return nullptr.
Pick-to: 6.2
Fixes: QTBUG-98247
Change-Id: Iff1dbd24fa7ca09098fe49c179770356c966251d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QTabBar implements wheelEvent to move the current index up or down. This
is useful for clicky mouse wheels, but a bad user experience when using
a kinetic wheel or touch pad, as every pixel movement will change the
current index.
Instead, scroll the entire tab bar when the wheel event comes from a
device that supports scroll phases, without changing the current index.
As drive-by's, fix the test introduced in aa09bea00c to
not leak memory or leave a test-specific style set on the QApplication
instance, which can break other tests.
Also, make relevant layout code in QTabBar respect the usesScrollButtons
property, const'ify local variables, and return an accepted QWheelEvent
if the event resulted in a change.
[ChangeLog][QtWidgets][QTabBar] Scrolling with a kinetic wheel or touch
pad scrolls the entire tab bar, without changing the current index.
Change-Id: I990e51466dd25c741877bbf0e197449f897a9efb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Mention that the futures returned by continuations will stay
uninitialized, until the corresponding continuation/handler starts
executing and do some general improvments to make the docs more
readable.
Task-number: QTBUG-97582
Pick-to: 6.2
Change-Id: I141ff1630b22ec7a856a457a41a69efec980d44b
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The slider is very touch friendly from macOS 11 on, and the knob is quite
large. Give it some extra pixels, and adjust the test accordingly.
Pick-to: 6.2
Task-number: QTBUG-98093
Change-Id: Iedf6db1081cdd4013ca29ce760aea1e0361b1123
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This change allows canceling the chain of continuations attached to a
future through canceling the future itself at any point of execution of
the chain.
[ChangeLog][QtCore][Important Behavior Changes] The chain of
continuations attached to a future now can be cancelled through
cancelling the future itself at any point of the execution of the chain,
as it was documented. Previously canceling the future would cancel the
chain only if it was done before the chain starts executing, otherwise
the cancellation would be ignored. Now the part of the chain that wasn't
started at the moment of cancellation will be canceled.
Task-number: QTBUG-97582
Change-Id: I4c3b3c68e34d3a044243ac9a7a9ed3c38b7cb02e
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This feature can easily be backported to our bundled version of libxcb
because the feature is pretty much self-contained (just a couple of new
events and parsing support) and does not depend on newer features of
libxcb that have appeared since our bundled version of 1.13.
Change-Id: If965e3de8b898286cd61c7fddbf335894f3a3ff5
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Most methods just do the same thing that is implemented in QList,
so just use QList methods
The QStack::pop() implementation should no longer go through the
resize which is likely slower, expands to more-code (unless optimized
away neatly) than erasure of single element through QList API (which
we optimized at some point to be fast)
It is also meaningless (afair) to have `inline` keyword when a method
is both declared and defined within the class' body, so we can drop
that as well
Change-Id: If9de3429be7418ed0ae13c571e28556a358eab05
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Adding new entries to QOperatingSystemVersion in patch releases
was previously breaking our BC guarantees because the entries are
exported, thus users cannot freely switch between different
patch-releases without a recompile if they adopted the new entries.
Move the data itself to a base class so that the entries can be
constructed inline.
Task-number: QTBUG-97808
Change-Id: Ic44f07488af8a04a3bedc10bebb740c4d68f43f3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The actual module build is done in-tree and after this attempting
to do shadow build of the dirty source directory causes issues in
some modules.
Pick-to: 6.2
Change-Id: I74bca186b238c5c1f10576b4f821efdf66b827ed
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
To allow using Android 12 APIs.
Pick-to: 6.2 5.15
Change-Id: I5e9da66c84457888ec723125d16876891232a99b
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There are still more failures, but these are low-hanging fruit.
Pick-to: 6.2
Change-Id: I3d3a1dc9e754bd4865c850cc1549b0b6fd6fa2f8
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
If a line edit is read-only, it only means that the _user_
should not be able to change the text. Qt itself (or the
application, by e.g calling setText()) should not have
this restriction.
For the QPA plugins to be able adjust the current selection from
selection handles, we should always process input method events.
It's the callers responsibility to ensure that the focus object
supports the actions it sends to the focus object (like ImReadOnly,
or ImhNoPredictiveText), and not QLineEdit.
This patch will therefore remove the check for
shouldEnableInputMethod() before processing the event. This will
allow us to adjust the selection from the QPA plugin (iOS/Android).
Task-number: QTBUG-91545
Change-Id: Id664ac3605a3fa0bf207635ed31d24c045d29a07
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A widget (e.g QLineEdit) will set WA_InputMethodEnabled to
false if it's read-only. But it can still contain selected
text (e.g from a mouse drag). In many cases, it therefore
makes sense to be able to query the focus object for what
that selection is, e.g to be able to show selection handles
from the QPA plugin (iOS/Android).
Therefore, remove the check if a widget has WA_InputMethodEnabled,
and always process the query. The caller can always check this
flag himself (or Qt::ImEnabled) before sending the query, if needed.
Task-number: QTBUG-91545
Change-Id: Ia3dfa289283b5c157ba47cf0b508f9fddadd2861
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Computing the start of the first day's number of milliseconds since
the epoch overflows, but adding enough seconds within the day would
have brought us back inside the representable range. So, for days
before the epoch, add a negative number of milliseconds from the end
of the next day instead of a positive number of milliseconds from the
(possibly unrepresentable) start of the target day. This is another a
follow-up to commit 2b26dea51b
Change-Id: I2e0c68d7012db85dfe7da4a8a20ba95368178ed1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
It's the modern recommended way to do it.
Change-Id: I10db128348014b316c1772d18396f272b0a2b766
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QMultiHash::operator== crashes when comparing two unequal objects.
This patch fixes it.
Pick-to: 6.2
Fixes: QTBUG-98265
Change-Id: Ibf9fef3372a2b4581843be5f25e65cc9a55ef64d
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This adds three categories:
- qt.core.library
- qt.core.plugin.loader
- qt.core.plugin.factoryloader
plus the "qt.core.plugin.elfparser" category (only available in
developer builds).
All three use the new Q_LOGGING_CATEGORY_WITH_ENV_OVERRIDE technique
which enables their debugging if the QT_DEBUG_PLUGINS=1 variable is set.
As a consequence, some warnings were downgraded to debug messages. I've
only left as warnings situations where a real problem occurred, since
they now get printed by default: failures to open or mmap a file,
corrupt plugin metadata (but not scan of non-plugins), use of
QPluginLoader with a static build of Qt.
Drive-by update of some messages to make them prettier and/or use
qUtf16Printable().
Change-Id: I3eb1bd30e0124f89a052fffd16a752acfe89c19e
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Check that a file name, not the full path, contains a dot.
Fixes: QTBUG-59401
Pick-to: 5.15 6.2
Change-Id: I193b2ae457a3ac6a460524dbf200786eb3461cef
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We use QMetaObject to invoke the "queryFocusObject" function. But if
the current focus object doesn't implement this function, we get a
"QMetaObject::invokeMethod: No such method" warning.
This patch will add a check if the focus object supports IM queries
before trying to call "queryFocusObject", to avoid the warning.
Task-number: QTBUG-91545
Change-Id: I3aa8bd2d4bf57bd42c2d77ed71174ec4f9951f81
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The focus object can emit selection updates (e.g from mouse drag), and
accept modifying it through IM when dragging on the handles, even if it
doesn't accept text input and IM in general (and hence return false from
inputMethodAccepted()). This is typically the case for read-only text fields.
So we should listen for selection changes and enable handles also for
this case (unless the IM hints tells us explicitly not to use handles/edit menu).
Fixes: QTBUG-91545
Change-Id: I2855505fc229e954b2c43f5e11374e64bba7eb4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In Qt, Qt::ImEnabled means that the focus object accepts text input from
input method (IM) events. But the IM API also contains API for dealing
with text selections. Text input and text selections are logically two
different operations, but since IM makes use of selections to implement
text input (like selecting a word to suggest a spelling correction), it's
understandable that they are combined into to same API.
So when a focus object reports Qt::ImEnabled to be false, it only means
that it doesn't accept input. E.g a TextArea in QML with "readOnly:true"
will set Qt::ImEnabled to false. At the same time, it can have
"selectByMouse:true", which lets you select text with the mouse.
This behavior is consistent in Qt, for both Quick, Controls 2 and Widgets.
Since we want to support any selections done in controls/widgets on iOS
with selection handles and edit menus, regardless if the focus object
accepts input or not, this patch will set the QIOSResponder (with read-only
actions) as first responder when we detect a focus object with Qt::ImReadOnly.
This means that if a query for Qt::ImReadOnly returns "true", we take that
to mean that it implements the IM API, but without accepting input.
Task-number: QTBUG-91545
Change-Id: I07349909a3bca81f484a2e9af9672428dca62c49
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QIOSTextInputResponder has two responsibilities; It takes care of
handling text input from UIKit, and to implement first responder
actions related to the edit menu, like copy and paste.
Currently the responder offers both writable (paste) and
readable (select, copy) actions. Because of the former, it means
that it can only be used for focus objects that accepts text input.
Since we also want to be able to show an edit menu for selections
done on a read-only input field, this patch will factor out the
read-only actions we want for that case into a QIOSTextResponder
base class. An instance of this class can be used as first responder
for a focus object that has read-only text, but otherwise doesn't
support text input. This part is implemented in a subsequent patch.
The remaining set of writeable actions, together with input method
handling, will continue to be in the QIOSTextInputResponder subclass.
Task-number: QTBUG-91545
Change-Id: I1c215bb509eb7820c6c60f7ad806f61a5de02ded
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We use QMetaObject to invoke the "queryFocusObject" function. But if
the current focus object doesn't implement this function, we get a
"QMetaObject::invokeMethod: No such method" warning.
This patch will add a check if the focus object supports IM queries
before trying to call "queryFocusObject", to avoid the warning.
Task-number: QTBUG-91545
Change-Id: I3aa8bd2d4bf57bd42c2d77ed71174ec4f9951f81
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The focus object can emit selection updates (e.g from mouse drag), and
accept modifying it through IM when dragging on the handles, even if it
doesn't accept text input and IM in general (and hence return false from
inputMethodAccepted()). This is typically the case for read-only text fields.
So we should listen for selection changes and enable handles also for
this case (unless the IM hints tells us explicitly not to use handles/edit menu).
Fixes: QTBUG-91545
Change-Id: I2855505fc229e954b2c43f5e11374e64bba7eb4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In Qt, Qt::ImEnabled means that the focus object accepts text input from
input method (IM) events. But the IM API also contains API for dealing
with text selections. Text input and text selections are logically two
different operations, but since IM makes use of selections to implement
text input (like selecting a word to suggest a spelling correction), it's
understandable that they are combined into to same API.
So when a focus object reports Qt::ImEnabled to be false, it only means
that it doesn't accept input. E.g a TextArea in QML with "readOnly:true"
will set Qt::ImEnabled to false. At the same time, it can have
"selectByMouse:true", which lets you select text with the mouse.
This behavior is consistent in Qt, for both Quick, Controls 2 and Widgets.
Since we want to support any selections done in controls/widgets on iOS
with selection handles and edit menus, regardless if the focus object
accepts input or not, this patch will set the QIOSResponder (with read-only
actions) as first responder when we detect a focus object with Qt::ImReadOnly.
This means that if a query for Qt::ImReadOnly returns "true", we take that
to mean that it implements the IM API, but without accepting input.
Task-number: QTBUG-91545
Change-Id: I07349909a3bca81f484a2e9af9672428dca62c49
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QIOSTextInputResponder has two responsibilities; It takes care of
handling text input from UIKit, and to implement first responder
actions related to the edit menu, like copy and paste.
Currently the responder offers both writable (paste) and
readable (select, copy) actions. Because of the former, it means
that it can only be used for focus objects that accepts text input.
Since we also want to be able to show an edit menu for selections
done on a read-only input field, this patch will factor out the
read-only actions we want for that case into a QIOSTextResponder
base class. An instance of this class can be used as first responder
for a focus object that has read-only text, but otherwise doesn't
support text input. This part is implemented in a subsequent patch.
The remaining set of writeable actions, together with input method
handling, will continue to be in the QIOSTextInputResponder subclass.
Task-number: QTBUG-91545
Change-Id: I1c215bb509eb7820c6c60f7ad806f61a5de02ded
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
initStyleOption should initialize the state based on which controls are
pressed or hovered, not only when painting but also when calling other
style APIs.
Pick-to: 6.2
Task-number: QTBUG-98093
Change-Id: I482793b7de38657aa36a20d0abab8845155ad0e9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
QTimerInfoList::timerWait() does not update the timespec
out argument if there are no active timers, which caused
the current code to calculate an arbitrary toWaitDuration.
Instead use the timerWait() return value, and clear any
native timers if there are no active Qt timers.
Pick-to: 6.2
Change-Id: I7d5ec4c2930000bece6f6ea6c63e76f4df543b04
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Don’t exit from the timer callback if there is no main
thread event dispatcher, since it could be that the main
thread event dispatcher is of the old event dispatcher type.
Pick-to: 6.2
Change-Id: Ibb7a34a99e2001b52d2a985022f5baa7cd2152bf
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
In addition, added the missing warninglimit
entry to a few doc configs.
Change-Id: I51b9d2ad66123a2a9673a3b42870662641375e6b
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Use std::integral_constant to avoid instantiating QIntegerForSize<16>,
caused by 2b26dea51b
Change-Id: Ia6f49a1dcd82835c7e76200a650767fc519eab90
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Cargo-cult copied this from somewhere, unnecessarily. This just made the
code bigger for no reason.
Task-number: QTBUG-97950
Pick-to: 6.2
Change-Id: Ice04365c72984d07a64dfffd16b48520d42c7043
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Using QFile::decodeName, not QString::fromLocal8Bit.
Pick-to: 6.2
Change-Id: Ice04365c72984d07a64dfffd16b47dcbfee23341
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
