mirror of
https://github.com/AntennaPod/AntennaPod.git
synced 2026-08-18 11:05:49 +00:00
f7f0314888
### Description The BarChartView (as used in the Years tab of the Statistics screen) uses two colors. In the default theme (without dynamic colors) those are blue and purple. When you turn on dynamic colors the purple stays and the blue changes to a very dark or light color with just a hint of your dynamic color. In my opinion, that looks bad. I've changed it so that the default blue and purple are used, even if dynamic colors are on. See the screenshot below for comparison. The old version is on the left, the new version is on the right. The top half is with the default theme, the bottom half is with a green dynamic color. <img width="2160" height="2916" alt="image" src="https://github.com/user-attachments/assets/f8a12340-c08d-401d-ba48-9f81e96e78aa" /> I've also tried to use two dynamic colors, a lighter one and a darker one, but have not found a configuration that looks good in all situations and with all possible dynamic colors. In the old version the blue in the default-dark case was a bit lighter than in the new version but since we don't have two variants of the purple color and that distinction wasn't made on the pie chart, I think it is okay to no longer do here as well. ### Checklist <!-- To help us keep the issue tracker clean and work as efficient as possible, please make sure that you have done all of the following. You can tick the boxes below by placing an x inside the brackets like this: [x] --> - [x] I have read the contribution guidelines: https://github.com/AntennaPod/AntennaPod/blob/develop/CONTRIBUTING.md#submit-a-pull-request - [x] I have performed a self-review of my code, going through my changes line by line and carefully considering why this line change is necessary - [x] I have run the automated code checks using `./gradlew checkstyle lint` - [x] My code follows the style guidelines of the AntennaPod project: https://antennapod.org/contribute/develop/app/code-style - [ ] I have mentioned the corresponding issue and the relevant keyword (e.g., "Closes: #xy") in the description (see https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) - [ ] If it is a core feature, I have added automated tests (I don't think an issue or adjustments to tests are needed.)