[core] wrong color variable names after new UI update

[Tetrax-10]

🔍 Have you checked Spicetify.app page for your issue?

• I have checked the FAQ

🔍 Is there already an issue for your problem?

• I have checked older issues, open and closed

ℹ Environment / Computer Info

- Spotify version: 1.1.94.872.g7a9200fe
- Spicetify version: 2.13.1

📝 Description

Wrong color variable names after new UI update

📸 Screenshots

Player

Sidebar

[kyrie25]

If you are able to, can you test some more and maybe provide an comprehensive list of which color variables are incorrectly applied? Would speed up the process by a lot.

[kyrie25]

Currently Spotify supports both their legacy and new layout at the same time as shown in their xpui.css

Though it may be temporarily patched via Regexp selecting those specific styles with .nav-alt, or to forcefully apply the colors with !important, it seems as though once Spotify themselves decides to dump the legacy layout from their releases both these solutions won't be plausible anymore.

For --spice-sidebar, the colors are now shared with --spice-main as they share the same CSS variable:

As for the player, their color is now shared with the black background of the whole app (via setting background: none)

Both of these can't be simply solved by changing values in the xpui files, nor does looking for specific class names and change the ruleset as it would require classes to be mapped at all times, while Spotify client's HTML layout and CSS ruleset applied to them are subjected to change at any times.

Currently I have come up with 2 stable solutions:

1. Maintain our own CSS snippet bundled into the CLI to somewhat preserve the colorings of previous themes.

• This, in itself, is not really stable because of the aforementioned points, we would probably need to publish a lot more releases to match the stylings once it changes and the CSS map must always be patched right after a class name changes.
• We could also shift this onto Marketplace's side, and have it maintained there, but not sure how stable it would be still. The caveat for this however, is that users have to be made aware that such snippet exists and install them, else legacy themes would still break their client.

2. Change the current color.ini color key strings to adapt with the new UI.

• Specifically, we would need to phase out --spice-sidebar and --spice-player in favor of a new color key for the client's background, as those key names are no longer accurate and does not serve the same purpose as before.
• This would require all current theme developers to adapt with the new changes, but it would ensure better maintainability in the long run (at least as long as this layout is used), as patching colors would only depend in the color values like it does currently and we would not need to publish CLI releases as often.

Either way, we will need to phase out on some support for the legacy layout as the color values are different to avoid replacing colors of the wrong element as shown on this issue.
May I have your opinions on this? @afonsojramos

[Tetrax-10]

If you ask me, I will go with 2nd, stable solution, we should always go with the flow of Spotify updates. So, it will be easy to maintain. Theme's devs should adopt to new updates. we should prob wait for their new UI final release as current CSS is supporting two diff UIs and color schemes. once a/b testing is over we will get their new color scheme and then we adopt that and release a patched CLI.

[Tetrax-10]

If you are able to, can you test some more and maybe provide an comprehensive list of which color variables are incorrectly applied? Would speed up the process by a lot.

the whole thing has changed. As mentioned in the above comment we should wait for Spotify to stable release their UI

[kyrie25]

If you ask me, I will go with 2nd, stable solution, we should always go with the flow of Spotify updates. So, it will be easy to maintain. Theme's devs should adopt to new updates. we should prob wait for their new UI final release as current CSS is supporting two diff UIs and color schemes. once a/b testing is over we will get their new color scheme and then we adopt that and release a patched CLI.

I do also prefer following the 2nd solution as it'd be more sensible to do so, but as this is a major breaking change, we need many different perspectives and opinions before going forward so as to make it the most beneficial for all current, new theme devs and the users.

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[CursedSpiderBoi]

we still have this issue?

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!

[ok-coder1]

What happened to GitHub Actions? It's marking stale after stale after stale after stale and so on...

But this issue is stale. It was opened in 2022 and it's 2024 now (2 years).

[ok-coder1]

Anyway, is this issue fixed?

[rxri]

What happened to GitHub Actions? It's marking stale after stale after stale after stale and so on...

But this issue is stale. It was opened in 2022 and it's 2024 now (2 years).

Any activity related to this issue is marked as „not stale anymore”
And no, it’s not fixed

[github-actions]

Marking this issue as stale.

Let someone know if I'm wrong, after all, I'm just a bot!