ActionRows are row widgets with associated actions. Left and right actions are triggered by swipes,
and center actions are triggered with an interaction.
Details
import QtQuick 2.12 import QtQuick.Controls 2.12 import QtQuick.Window 2.12 import org.kde.kirigami 2.12 Window { visible: true width: 640 height: 480 ListView { anchors.fill: parent model: 10 delegate: ActionRow { width: parent.width leftAction: Action { text: "Copy" onTriggered: { print("Copy triggered") } } centerAction: Action { onTriggered: { print("Center triggered") } } rightAction: Action { text: "Delete" SwipeAction.foregroundColor: "white" SwipeAction.backgroundColor: "#bf0039" SwipeAction.isDelete: true icon.name: "edit-delete" onTriggered: { print("Delete triggered") } } } } title: qsTr("Hello World") }
Diff Detail
- Repository
- R169 Kirigami
- Branch
- actionrow (branched from master)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 20513 Build 20531: arc lint + arc unit
Are we certain about naming here: SwipeAction.isDelete? Maybe SwipeAction.collapse ? It doesn't necessarily have to be a real "delete" action that is backing this, maybe all you want to convey with the name of this setting is that the list entry will be collapsed in an animation?
my gripe is that is a lot of javascript which could be simply implemented with a swipedelegate, having less heavy javascript which is a serious problem when used in delegates.
also a component like that back then was chosen to not be added by purpose in part because gesture-wise conflicts with the navigate back of pagerow and in part because every component added in kirigami needs to work as is on the desktop as well, modifying itself as much as needed.
(in this case it would get fixed buttons for the actions at the edges i guess)
Personally I don't find Kirigami's swipe-left-and-right-to-navigate-through-the-stack gestures to be very useful. You generally only ever use a swipe to go backwards, because to navigate forward you just tap the item. And having these swipes bound to pagerow navigation prevents the use of more useful gestures like these. I find these kinds of gesture-actions super useful in iOS and Android apps (particularly email apps where I use it to delete emails quickly).
every component added in kirigami needs to work as is on the desktop as well, modifying itself as much as needed.
(in this case it would get fixed buttons for the actions at the edges i guess)
This would suggest to me that we need to add these gestures to an even higher level component, or to add this to a BasicLictItem with leftSwipeAction: and rightSwipeAction properties or something, kind of like how SwipeListItem shows buttons on desktop. That way it the component would have buttons on desktop, and use the specified swipe actions on mobile automatically.
I would really not want to have to have an explicit back button. I find both going back by gesture and having a non destructive back action so that you can undo it a very central thing, to which i'll never renounce.
This would suggest to me that we need to add these gestures to an even higher level component, or to add this to a BasicLictItem with leftSwipeAction: and rightSwipeAction properties or something, kind of like how SwipeListItem shows buttons on desktop. That way it the component would have buttons on desktop, and use the specified swipe actions on mobile automatically.
SwipeListItem should just trigger when there is only one action, really (and that one doesn't conflict because the swipe is from the screen edge)
needed probably a graphical way to make it obvious that this will trigger on release rather than just showing the action