UnigramDev/Unigram/develop • caedfcc • 2 files, +54/-17 Give a short settings page an area that hit-

UnigramDev/Unigram/develop • caedfcc • 2 files, +54/-17
Give a short settings page an area that hit-tests

SettingsStickersPage works, and its ScrollingHost is a TableListView, so none of
the scrolling-host code runs for it at all. An ancestor source does get the pan
there, which means the scroller was never the whole story.

The discriminator is hit-testing. SettingsPanel is a bare Panel, and a Panel with
a null Background does not hit-test its own area. Its rows hit-test themselves,
which is why the gesture always worked on a page long enough to be all rows and
nowhere on the empty part of a short one - and why Stickers works from the other
direction, its ListViewItems being real content. With no hit there is no element
to walk up from and no source is ever found.

So the height added in the last commit bought nothing on its own. It needs a
Background to go with it, and Transparent paints the same as null.

Also flips the transition to FromRight. The frame inverts the effect on a back
navigation, so FromRight is what slides the uncovered page in from the left, and
it is the same value TLNavigationService passes going forward.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 54eac9b • 2 files, +46/-96
Take back the two fixes for a cause that was not the cause

Advanced and Power Saving fail over text and buttons, not only over empty space,
so neither the content falling short of the viewport nor a bare Panel declining
to hit-test its own area can be what is stopping them. Both were guesses, both
mutated pages this control does not own, and neither moved the symptom.

The scroller theory that started the sequence is doubtful too: SettingsStickers
works, and its host is a TableListView that ConfigureBackGestureContent skips
altogether, so an ancestor source is evidently enough somewhere. The source it
adds is left in place but is not to be treated as load-bearing.

What is left is a page whose XAML matches, element for element, pages that work.
The notes record what has been ruled out so the next attempt starts from
evidence rather than from another reading of the markup.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

UnigramDev/Unigram/develop • 3da7ee8 • 2 files, +47/-16
Keep the scroller manipulable so the pan stays a manipulation

Advanced and Power Saving take the gesture once the window is small enough for
their content to overflow, and refuse it at any size where it fits. That is the
whole of it.

ScrollMode.Auto turns the manipulation off when there is nothing to scroll, and a
touchpad pan over an element that cannot be manipulated is never classified as
one - so no interaction source is consulted anywhere up the tree and the gesture
is absent rather than misrouted, which is why no chip ever appeared.

Every settings page declares VerticalScrollMode="Auto". The difference between
the ones that worked and the ones that did not was never the markup, which is
identical, but whether the content happened to overflow at the size the window
was. Enabled holds the manipulation open regardless of extent, and costs nothing
here: there is still nothing to scroll, so nothing becomes scrollable that was
not already.

The declared value is restored when the page is left.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

#unigram