Debian Patches

Status for kf6-kirigami/6.13.0-2

Patch Description Author Forwarded Bugs Origin Last update
upstream_e3c6af3b_layouts-Always-relayout-on-geometry-changes-in-ToolBarLayout.patch [PATCH] layouts: Always relayout on geometry changes in ToolBarLayout
Otherwise we end up with several corner cases where the implicit width
is the same as width but we still have actions hidden.		 Arjen Hiemstra <ahiemstra@heimr.nl> no 2025-04-07
upstream_81352c22_layout-Set-implicit-width-of-ToolBarLayout-before-using-its-width.patch [PATCH] layout: Set implicit width of ToolBarLayout before using its width

Split setting implicit size into setting width and height separately, so
that we if we use width() it will use the implicit width if no width was
set yet. This avoids us hiding all actions because width is 0, only to
then show them again because implicit width (and thus width) is now a
valid value.		 Arjen Hiemstra <ahiemstra@heimr.nl> no 2025-04-07
upstream_82abc769_controls-Fix-link-activation-for-text-of-InlineMessage.patch [PATCH] controls: Fix link activation for text of InlineMessage
Rather than stretching both the label and toolbar across the entire
inline message, use implicit width for both, unless either would become
larger than the InlineMessage width. Most importantly, since the toolbar
only takes space that is not used by the text, this avoids links in the
text not working correctly.		 Arjen Hiemstra <ahiemstra@heimr.nl> no upstream 2025-04-07
upstream_2c6cd90f_controls-Improve-calculation-of-InlineMessage-implicit-height.patch [PATCH] controls: Improve calculation of InlineMessage implicit height

If the text isn't long enough to wrap into mulitple lines, but we have
many or large actions such that the actions are still put below the
text, the actions and close button would overlap because the close
button is not accounted for. To fix that, always anchor the actions at
the bottom and calculate a more proper implicit height for the entire
inline message that accounts for close button height if it is visible.		 Arjen Hiemstra <ahiemstra@heimr.nl> no 2025-04-08
upstream_bae0957d_controls-Remove-redundant-states-from-InlineMessage.patch [PATCH] controls: Remove redundant states from InlineMessage
States describe changes from a base state. The base state can just be
declared normally, there is no need to declare it as a separate state.
This fixes centering the close button in single-line inline messages,
because the "centered" state was never activated.		 Arjen Hiemstra <ahiemstra@heimr.nl> no 2025-04-08
upstream_fb21ee82_WheelHandler-smooth-scroll-for-a-greater-variety-of-movement-sizes.patch [PATCH] WheelHandler: smooth scroll for a greater variety of movement sizes

Duration is based on the duration and movement for 120 angle delta.
Shorten duration for smaller movements, limit duration for big movements.
We don't want fine deltas to feel extra slow and fast scrolling should still feel fast.
Minimum 3 frames for a 60hz display if delta > 2 physical pixels
(start already rendered -> 1/3 rendered -> 2/3 rendered -> end rendered).
Skip animation if <= 2 real frames for low refresh rate screens.
Otherwise, we don't scale the duration based on refresh rate or
device pixel ratio to avoid making the animation unexpectedly
longer or shorter on different screens.		 Noah Davis <noahadvs@gmail.com> no upstream 2025-04-14
upstream_bf7ead57_tst-scrolling-qml-don-t-set-default-angle-delta-to-verticalStepSize-don-t-test-if-smooth-scrolling-is-enabled-when-testing-angle-delta-moves.patch [PATCH] tst_scrolling.qml: don't set default angle delta to verticalStepSize, don't test if smooth scrolling is enabled when testing
angle delta moves

While arbitrary angle deltas are allowed, setting the default angle delta size to verticalStepSize is not semantically correct because verticalStepSize is not an angle delta.

We shouldn't make more assumptions about WheelHandler's internal logic than necessary since there is already a way to avoid failing the test when smooth scrolling is enabled.		 Noah Davis <noahadvs@gmail.com> no 2025-04-14
upstream_5bf798c3_Fix-ActionTextField-RTL.patch [PATCH] Fix ActionTextField RTL
This got broken in d8cbb0fd050861a0e08fd45192d311b65d2d4dc3, which was
not technically correct; if it worked at the time, it broke since then.

This reverts d8cbb0fd050861a0e08fd45192d311b65d2d4dc3		 Nate Graham <nate@kde.org> no upstream 2025-05-13
upstream_d803ca35_SearchField-fix-RTL-search-icon-positioning.patch [PATCH] SearchField fix RTL search icon positioning
We're overriding the value of LayoutMirroring.enabled unnecessarily and
incorrectly, causing the icon to always appear on the left regardless of
RTL. Just let it cascade to this component normally.		 Nate Graham <nate@kde.org> no upstream 2025-05-08
upstream_481ee938_controls-PageRow-don-t-announce-StackView-over-screen-readers.patch [PATCH] controls/PageRow: don't announce StackView over screen readers

PageRow has an internal StackView; it defaults to the Accessible.role
LayeredPane, which is by default announced by screen readers (or at
least by orca). This may be correct in some circumstances, but not here:
it's a purely internal object that has no user relevance; hearing
LAYERED PANE ZERO ITEMS every time a page in a PageRow is entered is
confusing to screen reader users, they have typically no idea what it
means, and if they do there is little they can do with this
information. (I guess it indicates whether a modal layer is open, but in
practice I couldn't seem to actually get this to work, and it seems
better to indicate when a modal layer is open, not every single time
when there isn't one - and that is a separate issue.)

Instead we can set its role explicitly to Pane, that marks it as a
filler in Accerciser and orca does not read it out every time.		 Christoph Wolk <cwo.kde@posteo.net> no 2025-05-19

All known versions for source package 'kf6-kirigami'

Links