feat(QScrollArea): add scroll viewport to create overscrolling effect #17208
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When designing pages (lists, galleries, horizontal scrollers) that have overlays (headers, footers, navigation panels on the sides) using QScrollArea results in either the scroll bar overlapping the content of the overlays (Figure 1) or scroll thumb/bar being hidden (and made inaccessible) by the overlays (Figure 2). In both cases, it leads to confusing experience for users.
If we add offsets to bottom/top of each (vertical and horizontal) scroll tracks, then it will effectively create a scrollable viewport within the container. The scroll behavior remains consistent and predictable to users, while developers get the freedom of creating overlays and adding acrylic/glass effects to their lists. See Figures 3-4.
What kind of change does this PR introduce?
Does this PR introduce a breaking change?
The PR fulfills these requirements:
dev
branch (orv[X]
branch)fix: #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
Figure 1.
Figure 2.
Figure 3.
Figure 4.
Other information:
Note 1: there is no documentation in PR yet, until the feature is approved and parameter names are "locked in".
Note 2: this includes code from #17041 and #17207 - once those are merged I will rebased this against the (updated) dev branch.