scrollbar for desktop builds in feature lists #4145
Conversation
Pull Request Test Coverage Report for Build 18618721137Details
💛 - Coveralls |
| anchors.right: listView.right | ||
| implicitHeight: listView.height | ||
| opacity: active ? 1.0 : 0.0 | ||
| Behavior on opacity { NumberAnimation { duration: 150 } } |
There was a problem hiding this comment.
| Behavior on opacity { NumberAnimation { duration: 150 } } | |
From the customers feedback I would not hide the scrollbar
There was a problem hiding this comment.
But usually every scrollbar on the internet has the hide, and it activate immediately with slight scroll.
Open to change it is we need to show scroll bar all the time!
There was a problem hiding this comment.
The thing is that the customer that raised this issue was not able to scroll and that's why they wanted the scrollbar. I would keep the scrollbar always visible and just have an effect to change colors when in use and when not.
There was a problem hiding this comment.
Understood, I would make the respective changes.
| policy: isMobile ? ScrollBar.AlwaysOff : ScrollBar.AsNeeded | ||
| visible: !isMobile | ||
| interactive: !isMobile | ||
| anchors.right: listView.right |
There was a problem hiding this comment.
isn't there API to set this in a clearer way?
There was a problem hiding this comment.
I mean, I don't see a better way then this here, it does seem like micro-managed properties but it best here. We could use a singleton QObject to have the logic which is also not the best case, as it will be over kill for this tiny change.
If you had a better idea, I am open to change.
There was a problem hiding this comment.
I think you misunderstood me. What I meant is why do you use both visible and interactive? Isn't one enough? And also from the documentation it looks like attaching Scrollbar to Flickable should be enough to set it's position, there is no need for anchors.
Withalion
force-pushed
the
dev/2025.8.0
branch
from
75c3747 to
eb72e98
Compare
Withalion
left a comment
Withalion
left a comment
There was a problem hiding this comment.
On second thought, it would make more sense to move the scrollbar directly into MMListView and/or MMScrollView as we want the scrollbar for all lists in the app as mentioned in #4127 . Right now it would be just for feature list.
| import QtQuick | ||
| import QtQuick.Controls | ||
| import QtQuick.Layouts | ||
| import QtQml |
There was a problem hiding this comment.
Initially MMFeatureListPage directly had the scrollbar which has Qt.platform.os so I had imported it, I took it to the ListView now.
|
|
||
| policy: ScrollBar.AlwaysOn | ||
| visible: !isMobile && (root.contentHeight > root.height) | ||
| opacity: (pressed || root.moving) ? 0.7 : 0.4 |
There was a problem hiding this comment.
Shouldn't active be enough https://doc.qt.io/qt-6/qml-qtquick-controls-scrollbar.html#active-prop?
| opacity: (pressed || root.moving) ? 0.7 : 0.4 | |
| opacity: active ? 0.7 : 0.4 |
| } | ||
|
|
||
| ScrollBar.vertical.policy: ScrollBar.AlwaysOff | ||
| ScrollBar.horizontal.policy: ScrollBar.AlwaysOff |
There was a problem hiding this comment.
Isn't this the Qt docs-suggested way of disabling scrollbar https://doc.qt.io/qt-6/qml-qtquick-controls-scrollview.html#scroll-bars?
app/qml/components/MMScrollView.qml
Outdated
| ScrollBar.vertical: ScrollBar { | ||
| id: verticalScrollBar | ||
|
|
||
| policy: ScrollBar.AsNeeded |
There was a problem hiding this comment.
Why do we have a different value here compared to MMListView?
There was a problem hiding this comment.
Similar comments apply here as in MMListView
Case: Missing scrollbar for the desktop version for all the ListView components.
What has be been done:
Added slim scrollbar on the right side of the lists.
Scroll bar only activates for desktops; ex(macos, window, linux) and not any mobile builds
Scrollbar always visibile, but highlights on active more and passive on inactive.
Tested for mutiple page which uses ListView and the work of scrollbar
Screen.Recording.2025-10-23.at.12.18.39.PM.mov