We tried to make default behavior depend on the import version; but in
Controls that does not work well, because the QQuickTextField instance
is created in a style-specific QML file that does not use the same
import version that the user is using. So we work around it by adding
support for a Controls-specific env var to revert to pre-6.4 behavior.
Adding the autotest proves that the fallback was broken a different
way too: we didn't check selectByTouchDrag in all the necessary places.
Amends 650342de79
[ChangeLog][Controls][TextField] The selectByMouse property is now
enabled by default, but no longer enables selecting by dragging your
finger across text on a touchscreen. Platforms that are optimized for
touchscreens normally use special text-selection handles, which interact
with Qt via QInputMethod. You can opt out of the behavior change by
setting the environment variable
QT_QUICK_CONTROLS_TEXT_SELECTION_BEHAVIOR=old.
Task-number: QTBUG-10684
Task-number: QTBUG-38934
Task-number: QTBUG-101205
Pick-to: 6.4
Change-Id: If1c1d6bd9c538f52022ae06d5252d178a1ae5a38
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When you drag a finger across a TextArea, it should not select text.
- your finger probably covers several characters, so you can't see where
you're selecting until afterwards
- if the item is in a Flickable, flicking by touch should be prioritized
- if flicking happens, the text cursor should not move; but to avoid
losing too much functionality, we allow it to move on release, if
the TextArea gets the release (i.e. if it still has the exclusive
grab)
- TextArea's pressed, pressAndHold and released signals continue to
behave the same with touch as with mouse
As with the TextEdit change in 90d3fac73a,
we now distinguish mouse events that are synthesized from non-mouse
devices and avoid mouse-like behaviors as described above, but there is
no behavior change if the event comes from an actual mouse or touchpad.
In QQuickPressHandler::mousePressEvent() we give the original event's
device to the delayed press event, now that we check the device to
distinguish "real" mouse events from those that are synthesized from
touch.
[ChangeLog][Controls][TextArea] The selectByMouse property is now
enabled by default, but no longer enables selecting by dragging your
finger across text on a touchscreen. Platforms that are optimized for
touchscreens normally use special text-selection handles, which interact
with Qt via QInputMethod. You can opt out of the behavior change by
setting the environment variable
QT_QUICK_CONTROLS_TEXT_SELECTION_BEHAVIOR=old.
Pick-to: 6.4
Task-number: QTBUG-10684
Task-number: QTBUG-38934
Task-number: QTBUG-90494
Task-number: QTBUG-101205
Change-Id: Icbe81e547b1cf8d5e3cc3ed922f12c7b411ca658
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
TreeViewDelegate was using mouse event handlers to detect clicks
on the delegate and its indicator (to e.g toggle the expanded state
of a tree node). This had the effect that any pointer handlers installed
on the TreeView itself would be blocked from working, since the
delegate would accept the mouse events, and thereby stop propagation.
Since TreeView uses drag-, and tap handlers to perform selections
(installed by SelectionRectangle), using TreeViewDelegate as
delegate would basically stop selections from working.
Therefore, this patch will switch to use pointer handlers instead.
Pointer handlers are by default non-blocking, and will naturally
work better with other pointer handlers in the application, including
of course the pointer handlers installed on the TreeView itself.
The reason QQuickTreeViewDelegate was using mouse event handlers
from the start, was because it inherits QQuickAbstractButton, which does
the same. For that reason, we still need to
override mouseButtonPressed(), and ignore the mouse events, to
make sure that the QAbstractButton implementation doesn't block.
Instead we now call the appropriate mouse handling functions in
QAbstractButton directly from the pointer handlers.
Since we don't use mouse event handlers anymore, this also has the
advantage that we no longer need to recommend users to install custom
pointer handlers on a child item of the delegate - they can now be
installed directly on the delegate. Docs that described that
work-around are therefore removed/changed.
Fixes: QTBUG-105570
Pick-to: 6.4
Change-Id: I46d82175c577a27d083494960f1cad645f4d75a4
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
908aa77d16 hid old scroll bars, but
didn't account for the situation where the old scroll bars would be put
back into place, and so they never showed up.
In the case of the linked bug report, since there was a binding to the
ScrollView's contentItem, a default Flickable would be created. After
that binding was evaluated, the contentItem was set, causing the scroll
bars to be hidden (as part of the process of disconnecting from the old
flickable). To fix the issue, we now do the reverse of hideOldItem when
a new contentItem is set.
Fixes: QTBUG-104983
Pick-to: 6.2 6.3 6.4
Change-Id: I910259cc3e8f6a6231ae6c87c7d4f0f652bd0545
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Nate Graham
Before 6.4, it was only possible to make a selection in
TableView by using a SelectionRectangle. But in 6.4, you
can also make a selection directly in TableView by using
the shift+arrow keys. To make sure that a selection is
cleared either way on tap, move the implementation that
clears the selection from SelectionRectangle to TableView.
Pick-to: 6.4
Change-Id: Ic718763bf9b643cb3e3c04cc3b90c6ffcf9ca4b2
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
\target should be used to generate HTML anchors, while here it refers to
the argument `target` of the function.
Change-Id: I52f320ccb78f4ed3d4db59f9fc0ab7d6be0f27d0
Pick-to: 5.15 6.2 6.3 6.4
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The event filter was returning true when wheelEnabled was false,
but wasn't ignoring the event, meaning that propagation of the wheel
event stopped there, and items behind the ScrollView didn't get the
event even if ScrollView wasn't using it.
I'm not sure why it was done this way - the behavior isn't documented
and no auto tests fail when changing it.
Fixes: QTBUG-105164
Pick-to: 6.3 6.4
Change-Id: Ie826ccfc406b77606ef0c6f043dc48f42a18cdc7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Types that use declarative registration do not need
QML_DECLARE_TYPEINFO.
Fixes: QTBUG-104837
Change-Id: I3dadc1d4f638ed2ea7ee015bc229a875929e6387
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
In Qt6, users can get access to the popup positioner from the template
for QQuickMenu, but the symbols of the popup positioner were previously
not exported. So, export them, so that it can be used, and thus allow
users to override popup positioning behavior.
Task-number: QTBUG-105054
Pick-to: 6.4 6.3 6.2
Change-Id: I9ab31e81152d87b276507c3b80a014f568cc3e4f
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Controls shouldn't block hover from propagating by default.
This was a regression in Qt 6.2 compared to Qt 5.15, and was
fixed with 0c7b0a4306. But that
patch didn't consider many of the items that overrode hover
event handling from c++, like TextArea and TextField;
they too need to ignore hover events, to not stop propagation -
it's not enough to only do it in the base class.
This patch fixes the regression that some controls
and items were blocking propagation compared to Qt 5.15.
Fixes: QTBUG-104537
Pick-to: 6.4 6.3 6.2
Change-Id: Ie047da6ac7d5be5ea6fd52d5a5446787df6d10f5
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
So that users can use QT_NO_KEYWORDS when linking against QtDeclarative,
even if they are using private headers.
Docs, examples and tools are not touched because it's not necessary.
Pick-to: 6.4
Change-Id: Idc30797074aaa72576429ebdaaf915d7f5acf84e
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
When you drag a finger across a TextInput or TextField, it should
not select text.
- your finger probably covers several characters, so you can't see where
you're selecting until afterwards
- if the item is in a Flickable, flicking by touch should be prioritized
- if flicking happens, the text cursor should not move; but to avoid
losing too much functionality, we allow it to move on release, if
the TextInput or TextField gets the release (i.e. if it still has
the exclusive grab)
- TextField's pressed, pressAndHold and released signals continue to
behave the same with touch as with mouse
So now we distinguish mouse events that are synthesized from non-mouse
devices and avoid mouse-like behaviors as described above, but there is
no behavior change if the event comes from an actual mouse or touchpad.
Since most users want selecting text by mouse to "just work", and an
actual mouse is precise enough to do so, and dragging a Flickable with
the mouse is unintuitive (since most UIs don't allow it and most mice
have wheels), selectByMouse now defaults to true, and has the stricter
meaning that its name implies. To select text on a touchscreen, the
end-user needs to rely on text-selection handles, which are provided on
touch-centric mobile platforms, and could also be implemented from
scratch if someone builds a custom text field using TextInput.
[ChangeLog][QtQuick][TextInput] The selectByMouse property is now
enabled by default, but no longer enables selecting by dragging your
finger across text on a touchscreen. Platforms that are optimized for
touchscreens normally use special text-selection handles, which interact
with Qt via QInputMethod. You can opt out of the behavior change by
using an import version < 6.4.
[ChangeLog][Controls][TextField] The selectByMouse property is now
enabled by default, but no longer enables selecting by dragging your
finger across text on a touchscreen. Platforms that are optimized for
touchscreens normally use special text-selection handles, which interact
with Qt via QInputMethod. You can opt out of the behavior change by
using an import version < 6.4.
Pick-to: 6.4
Task-number: QTBUG-10684
Task-number: QTBUG-38934
Task-number: QTBUG-101205
Change-Id: I6d3158dd48896a0bed37cbc0b2da01d313a499f8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The element can get deleted when stopping the transitions. Also, only
register the change listener if we are going to keep the item.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-98769
Change-Id: I2fa6542fdc0dc92f3f1f0b20996cd59ce51a48cb
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Use CLASS_NAME instead of CLASSNAME.
The latter will be removed in the future.
Change-Id: I0f66b05b45b1c2ec904a405b5f2f18b7901ced9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I72c89a98c42bbc9234d8495e9e503bec81d11037
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The Item's palette property and Control's font property returns the
resolved value; its resolveMask is inherited from parent object, when
the return value is used in the qml. For example:
ApplicationWindow {
id: window
palette { window: "blue"; windowText: "blue" }
Control {
id: control
}
Button {
onClicked: {
control.palette.window = "red"
window.palette.windowText = "red"
console.log(control.palette.windowText)
}
}
}
In Button.onClicked, `control.palette` is the `resolvedPalette`
of Control, it's resolveMask is not 0. Next, the new value is assigned
to the control, then the control's "requestedPalette" will change to the
new value, and it's resolveMask also is not 0. Next,
`window.palette.windowText = "red"` changes the `windowText` palette for
the window; QQuickPaletteColorProvider::inheritPalette() will be called.
Because the resolveMask of `requestedPalette` is equal to the new
palette, the control will not inherit any colors from its parent. So
`console.log(control.palette.windowText)` was printing `qml: #0000ff`,
but the right result is `qml: #ff0000`.
When PaletteProvider is missing the inherited struct, fallbackPalette is
now used as parentPalette.
[ChangeLog][Controls] Controls now inherit palette and font from parents.
Done-With: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-With: yeshanshan <yeshanshan@uniontech.com>
Done-With: Shawn Rutledge <shawn.rutledge@qt.io>
Pick-to: 6.4
Fixes: QTBUG-101480
Change-Id: Ibe400f647512331352bf34dee42f908fb7a8d914
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
QQmlComponent::createWithInitialProperties() allows to pass non-existent
properties to create the object with. In this case, we still return a
valid pointer (pre-existing), however, the state of the component is
affected: there are errors internally that fail repeated calls even with
valid properties specified. Fix this, aligning to the behavior of
QQmlComponent::createObject() which is a QML counterpart of the same
function (to a degree)
Additionally, make required properties warnings also not break the
component state: if a required property is not set, we return nullptr
instead of object. The error state is affected but it gets cleaned
on the next creation call, allowing one to set the missing required
properties
Unify the logic (with slight deviations) between create() (the
non-incubator-accepting version), createWithInitialProperties() and
createObject() as all they all should do roughly equivalent things
[ChangeLog][QQmlComponent][Important Behavior Changes] Setting properties
via createWithInitialProperties() and setInitialProperties() no longer
affects the QQmlComponent's error state unless there are unset required
properties. A warning is issued when a property could not be set.
Fixes: QTBUG-101439
Change-Id: I814c00bc3715d7a54004c3fcd0af6ee6d50b0726
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
If someone catches mouse events under a SplitView handle, and
that handle uses containmentMask to extend hit testing, the mouse
events outside the handle's bounds are not handled by the SplitView.
Because of this containmentMask is not useful for hit testing.
[ChangeLog][QtQuick][SplitView] SplitView now correctly handles
mouse events when using containmentMask.
Task-number: QTBUG-82678
Fixes: QTBUG-87119
Fixes: QTBUG-97385
Pick-to: 6.2 6.3 6.4
Change-Id: I3f00a73f9d80f22575545dd8556af6c755aadaa6
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
For a custom menu control, when the contentItem does not inherit from
ItemView, the text overlaps. A related bug is QTBUG-53262, but this
problem is only fixed for the ItemView control.
Since the contentItem control can accept the Item control, I think the
repair only for ItemView has limitations. Therefore, this submission
cancels the restriction on the type of contentitem.
Pick-to: 6.3 6.4
Fixes: QTBUG-104470
Change-Id: I7e697e3cb993475d157a92f37d9512e4a9872387
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
* Add missing ingroup command to ItemDelegate to be listed by
annotatedlist command on qtquickcontrols2-delegates page
* Add missing image and description for CheckDelegate
Control on qtquickcontrols2-delegates page
Task-number: QTBUG-104157
Pick-to: 6.2 6.3 6.4
Change-Id: I0b8d830aeab348c763d4e716d5962258c9c82a77
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
UBSan checks the type_info of all objects accessed for possible
mismatches. QQuickLabelPrivate was not exported, but used in
tst_QQuickStyle, breaking UBSan builds.
Pick-to: 6.4 6.3 6.2
Change-Id: I9265c830f01417a0a1f38413139965559a509bdd
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Previously IBeamCursor was wrongly shown in case when TextEdit
was readonly and not selectable by mouse. Now ArrowCursor will be shown
in such case. Additionally removed own mouse cursor shape handling logic
in TextArea, so it will be unified now with derived logic from TextEdit.
This is a change from 23f78b6b76fb9350a472485e34857e1a4842e5d3:
we no longer attempt to restore a cursor that was set via setCursor().
[ChangeLog][QtQuick][TextEdit] TextEdit and TextArea now set their own
mouse cursors more consistently, but without regard for any external
call to setCursor().
Fixes: QTBUG-104089
Pick-to: 6.3 6.4
Change-Id: Iba4e0cb55d555b0f360d7856346ff9e8393b9e1e
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QQuickItemDelegate inherits QQuickAbstractButton, and adds
only a single property 'highlighted' on top. Since all the existing
TreeViewDelegates need this property, and since a TreeViewDelegate
is also conceptually an item delegate, it makes sense to inherit
from QQuickItemDelegate instead.
Pick-to: 6.4
Change-Id: I642fb19ab21f8e8ff447d73494aabe55c7cea25c
Reviewed-by: Mitch Curtis <mitch.curtis@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.
Pick-to: 6.4
Task-number: QTBUG-67283
Change-Id: I63563bbeb6f60f89d2c99660400dca7fab78a294
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When resizing the background, use setSize instead of setWidth and
setHeight to reduce the number of geometryChange calls when both width
and height get resized.
Additionally, setSize preserves bindings, which fixes the linked bug: We
would resize the background even when we have binding on height/width,
which would later overwrite the value again. With the porting to
bindable properties, the setWidth/Height calls would have destroyed that
binding. setSize avoids that issue.
Lastly, do not even attempt to overwrite the binding when we detect that
it exists.
Pick-to: 6.2 6.3 6.4
Fixes: QTBUG-102136
Change-Id: I16a99fd9f7d56f84b423b477d373e265e39d4094
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
The \l command with just one argument, size, has a competing
section1 link target, Size, in a different C++ file. Specifying the C++
class as the first argument to the link command will make sure that
the link goes to its intended target.
Fixes: QTBUG-103250
Pick-to: 6.3
Change-Id: Ibabd04986e033f7c401f9132d25be7c6f4e8e8d9
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
When TreeView is interactive, it should expand
tree nodes on mouse release (to not interfere with flicking).
Otherwise, if interactive is false, it should expand already
on mouse press (equal to how e.g Widgets work).
The current if-test that implemented this logic was
broken, and would fail when TreeView was not interactive.
Change-Id: I801a694b2dfd03875893bb2bda5c8ef3883dec75
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Removing the selection after a pointer click is normally done
by TableView. But since TreeViewDelegate accepts mouse
events, it needs to do this explicitly.
Change-Id: Id0d6879f5b0e014aa05f50487f89dd0a08bb21f5
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Ensure that items declared before and after the control itself do not
cause heap-use-after-frees due to deletion order.
Task-number: QTBUG-100396
Pick-to: 6.2 6.3
Change-Id: I3989bf1b9fc64b4ec86f241de2cb8bcd05c2f89d
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Send mouse and touch events through passive grabbers.
With support for passive grabbers, the drawer can now make itself a
passive grabber for the mouse when it is pressed inside the margin
area. It will then see the update events that are delivered to the
exclusive grabber, and can try to grab the mouse when the e.g. move
has progressed enough. Then the earlier grabber gets an ungrab event
that allows it to cancel the action.
Done-with: Doris Verria <doris.verria@qt.io>
Fixes: QTBUG-59141
Change-Id: Ie8e79c2ec2aa1f5a00056f23856bd0bed19af2d6
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We should start the selection in TableView at the position where the
user started the drag, and not where the centroid at the time when the
dragging gets active (which is an offset equal to the
mousePressAndHoldInterval property in QStyleHints).
Pick-to: 6.3 6.2
Change-Id: Ibe330d31c1e2c8022006a56b7119b1dcb3e0e5b9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
They are only called by QQuickOverlay, so move the logic there,
respecting the overlay's possible sub-scene delivery agent instead of
hard-wiring the event delivery to the QQuickWindow.
Change-Id: I629cc2cefb8757a876323d64de035bda92f24e5d
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We should avoid creating shortcuts for special keys like
Cancel (Back/Escape), as it can interfere with the user's own shortcuts
by e.g. requiring use of Keys.shortcutOverride, which itself can only
be sent to items with active focus, preventing users from overriding
Qt's global shortcuts in some cases.
[ChangeLog][Controls][Important Behavior Changes] Popups no longer
handle the Escape and Back keys by grabbing them as shortcuts, instead
they are treated as regular events. This also means that popups
that should be closable with the Escape or Back keys must have focus.
Task-number: QTBUG-79280
Change-Id: Iaf7249226d5766b2ab101630de5590b9524c56dd
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Dialogs and Menus should always have focus when they're opened,
especially now that the cancel key handling in
QQuickPopup/QQuickPopupItem is done via regular key events and not
shortcuts, as popups will now require focus in order to be cancelled
via keyboard.
[ChangeLog][Controls][Important Behavior Changes] Dialogs and Menus now
have their focus property set to true by default. Popups are unchanged,
meaning that popups that should be interacted with via keyboard
(including cancelling) should have focus set to true or
forceActiveFocus() called on them after opening.
Task-number: QTBUG-79280
Change-Id: Idd070f2b1e8180a34a0dadb6e11dc56e531df211
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Position of the ScrollBar handle is fixed when it's being resized except
when it's on the extreme side (position + size = 1). In this case, when
the width is growing, the handle size should grow and the position
should decrease as a result.
Fixes: QTBUG-98387
Change-Id: Ibb18c03a741bb4e5a19425a57f14a68d27d68d12
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QQuickPopups event handling code deals with two concepts: the handling
of events by the popup (accepting the event and becoming the grabber for
the relevant device in case of press events), and the blocking of events
to other items. For a plain popup that's ok, but events that aren't
blocked by the popup must be ignored by it to that they propagate
correctly.
QQuickDrawer, which subclasses QQuickPopup and overrides the blocking
logik (via QQuickDrawerPrivate::blockInput), conflates those two
concepts, which is not ok as QQuickDrawer is interactive and may accept
an event even if the event is not modally blocked. Press events that go
to the content item of the drawer are never blocked, but must get
accepted so that the drawer receives the following mouse moves.
Fixes: QTBUG-93649
Pick-to: 6.3 6.2
Change-Id: I254ccd843dc0250d334abb9b1062e7feffb86beb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
ListView only manages the positions of the visible delegates; but the
children of SwipeView are instantiated at startup. When we didn't set
their positions, if they are translucent, they were simply piled up
on top of each other until ListView got around to positioning them
during swiping. Between a055629f43 and
e10de033f4 SwipeView was calling
setCulled(true); we stopped doing that because of QTBUG-99547.
So now it makes sense to position the delegates the same way that
ListView will eventually position them... assuming there are no
other special cases for custom positioning. They are still
effectively "culled" by being outside the viewport, or the clip.
Fixes: QTBUG-102487
Task-number: QTBUG-51078
Task-number: QTBUG-51669
Task-number: QTBUG-99547
Pick-to: 5.15 6.2 6.3
Change-Id: I58afab55cc95a1d4a637111a9cca82e6177856ff
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
We can have QQmlDelegateModel pick specific roles from model items. That
can easily be done for variant maps, variant hashes, objects and
gadgets. We would like to do it for anything that has a
QMetaAssociation, but as we cannot get to the original type at that
place, it's currently not possible.
The special case about variant maps with exactly one item in variant
lists is clearly insane and therefore not included in the
generalization.
This requires some cleanup in the QQmlGadgetPointerWrapper. Passing the
wrapper itself to QMetaProperty::read() has always been a rather obscure
way of reading from the gadget.
Pick-to: 6.3
Fixes: QTBUG-102983
Change-Id: I84ecef980783e7137aa4d77070ddce47b6ead260
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
If the application has pointerNavigationEnabled set to false, we
should not expand or collapse the tree. The application has the
possibility to set this property to set aside all our internal
pointer navigation, and implement their own solution instead.
Change-Id: I3055c459f0ce5eac8d55f44b93fd50d3d8afef64
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
If we set configure to '-no-feature-quicktemplates2-multitouch'
and use a touch device, the touch events should be changed to mouse
events by deliverTouchAsMouse() function without going through
setAcceptTouchEvents().
Pick-to: 6.2 6.3
Change-Id: I5cb678d400073031de19a1aa7c91f583599c9c09
Reviewed-by: bumjoon.park <bumjoon.park@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When typing "B" in the text field of an editable ComboBox whose model
contains "Apple", "Banana" and "Coconut", and then hitting Enter, any
selected text should be cleared. This is how widgets behaves, and also
how ComboBox already behaves when typing a lowercase "b".
Change-Id: I18f28d246a7853280b2e2d3b4288278b9dd45ebb
Fixes: QTBUG-75197
Pick-to: 6.2 6.3
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Previously the attached object of TextArea was not visible to
tooling. Now with the proper QML_ATTACHED entry added, it can be used
with no issues.
Pick-to: 6.2 6.3
Change-Id: Iab3ae6bb13146082ec29eea52fdb7eb06ff37a1b
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
In Qt, input events are accepted by default, and item event handlers
ignore the event. Overrides of the event handlers don't have to do
anything explicit to mark events as handled, but can explicitly ignore
events (i.e. such events that hit transparent areas or are from devices
or buttons the item doesn't care about).
Controls, as of d88d9d6342, always
accepted events, even if they didn't do anything with it. This is
fundamentally breaking event delivery semantics, preventing control
implementations from selectively accepting or ignoring events depending
on event attributes.
Revert that behavior, and ignore events unless the handler override
returns true. Change all existing handlers to return true so that we
don't break existing controls. Controls that don't override handlers
will ignore the event, which will then propagate as per Qt's event
handling semantics.
The odd control out is Pane, which doesn't do anything with events, but
nevertheless returns true to stop propagation to controls covered by it.
In QWidget world we have special attributes for this kind of UI element,
WA_NoMousePropagation and WA_TransparentForMouseEvents. We might need
something similar in Quick to fix the bug that Drawer eats events in the
(invisible) drag margin, preventing controls underneath to receive them
with priority.
Task-number: QTBUG-59141
Change-Id: Ic1a347ce293c8e11dab958c076ee488834060839
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
Shawn Rutledge
Richard Moe Gustavsen
Mitch Curtis
Thibaut Cuvelier
Leticia Valladares
Chris Adams
Yuhang Zhao
Ulf Hermann
Joerg Bornemann
Lucie Gérard
JiDe Zhang
Andrei Golubev
Igor Bugaev
Chen Bin
Thomas Piekarski
Marc Mutz
Vladimir Belyavsky
Fabian Kosmale
Andreas Eliasson
Volker Hilsheimer
Soheil Armin
Bumjoon Park
Maximilian Goldstein