Repository navigation
Visible scrollbar thumb, and icons that survive a theme switch - #23
Merged
Merged
Conversation
The Simple theme takes a scrollbar's thumb and track from two neighbouring palette brushes. The quiet palette App.axaml restates leaves those a shade apart in Light (#F0F2F5 on #F6F7F9), and the pressed thumb lighter than the track, so a list that scrolls did not show it. Dark was weak the same way. Retuning the palette brushes was rejected: buttons, combo boxes and list hover states share them. The thumb gets a translucent mid-grey of its own instead, which needs no per-theme resource and reads on both tracks. Assisted-by: Claude:claude-fable-5-1:Claude Code
Two things went missing after switching theme, for unrelated reasons. Going Dark and back to Light left the monochrome toolbar icons light grey on a light background. The dark stylesheet was cleared by setting Css to null, but an SvgImage without a stylesheet falls back to the one its source was last loaded with - the dark one. Light now sets an explicit stylesheet that restates the icons' own colour. A screenshot request that switched the theme showed every text block built from Runs as blank, and left it blank afterwards. The watcher rendered the window in the same tick as the command, before the layout pass; Avalonia draws such a text block as empty in that state and its run cache keeps the empty result. The capture caused what it showed - a switch from the menu never did this. The watcher now runs the layout pass before it renders. Assisted-by: Claude:claude-fable-5-1:Claude Code
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Scrollbar thumb is visible against its track
The Simple theme takes a scrollbar's thumb and track from two neighbouring palette brushes. The quiet palette
App.axamlrestates leaves them a shade apart in Light (#F0F2F5on#F6F7F9) and makes the pressed thumb lighter than the track, so a list that scrolls - the branches list on the start page, for one - did not show it. Dark was weak the same way.The thumb now has a translucent mid-grey of its own, a step stronger on hover and when pressed. It applies to every scrollbar. The palette brushes are left alone because buttons, combo boxes and list hover states share them.
Checked in the running app in Light and in Dark, thumb at rest. Hover and pressed states were not captured.
Nothing goes missing across a theme switch
Two separate losses, found while checking the above in both themes.
Toolbar icons after Dark -> Light. The monochrome icons (filter, refresh, pull) stayed light grey on the light background.
Images.cscleared the dark stylesheet withCss = null, but anSvgImagewith no stylesheet falls back to the one its source was last loaded with, which is the dark one. Light now sets an explicit stylesheet restating the icons' own#202020. The mechanism was read from Svg.Skia's current source rather than the pinned version; the fix was confirmed in the running app.Text in a screenshot taken with a theme switch. A screenshot request carrying
menu:Darkshowed everyTextBlockbuilt fromRuns - pull request titles, the second line of each row - as blank, and they stayed blank.ScreenshotWatcherrendered the window in the same tick as the command, before the layout pass; Avalonia 12.1 draws such a text block as empty in that state and its run cache keeps the empty result. This was the harness causing what it showed: switching theme from the menu never blanked anything. The watcher now callsUpdateLayout()before it renders.Checked by repeating the sequence that failed -
menu:Dark, thenmenu:Light, a capture with each: text and icons are right in both themes.Testing
dotnet build Stampeded.slnx: 0 warnings, 0 errors. The test suite was not run; it coversStampeded.Coreand all three files are in the UI project.🤖 Generated with Claude Code