search

spicetify / cli

Command-line tool to customize Spotify client. Supports Windows, MacOS, and Linux.
https://spicetify.app
GNU Lesser General Public License v2.1
18.19k stars 716 forks source link

[Major release] Spicetify v4 #2657

Closed afonsojramos closed 4 months ago

afonsojramos commented 10 months ago

📝 Provide a description of the new feature

As more and more users with all levels of knowledge dive into the Spicetify world, we should adapt what we offer to better serve everyone. As such, a GUI is a must, so we should consider either moving an platform that suits our needs (such as Tauri/Rust), or adding GUI features to our codebase, such as with https://github.com/wailsapp/wails. The desired features are as follow:

User-experience:

Backend side:

➕ Additional Information

Happy to expand the above with ideas from the comments.

ohitstom commented 10 months ago

Downgrade option for Spotify

May i ask how this will be possible without a public download page of all versions, we have one google sheet manually managed but that seems hardly perfect...

jsHelpers would be independent of CLI tool

Could you elaborate on the meaning of this? I thought functionally we already do that, granted we have to update the executable along with it if thats what you mean.

May i suggest instead of separating jsHelpers from Spicetify so they can be updated separately, we package a "functional" set of jsHelpers, and on apply we remote fetch and update said files? that way offline users dont suffer, and we can only package what is needed on binary releases?

popular extension/theme?

i dont really agree with this, we would have to manually keep track of what stuff works and what we can ship with Spicetify. It also brings in to question how you expect to allow downgrading but most themes and extensions only support latest, would we be enforcing users to add supported version metadata to their repos?

we really dont want a bunch of issues for stuff that isnt made by us. probably best to stick with just suggesting "officially maintained" extensions or customapps, we might then finally be able to migrate the ones in the repo into their own that way too and people can suggest official ones to be added?

Everything else looks sweet though!

afonsojramos commented 10 months ago

i dont really agree with this, we would have to manually keep track of what stuff works and what we can ship with Spicetify. It also brings in to question how you expect to allow downgrading but most themes and extensions only support latest, would we be enforcing users to add supported version metadata to their repos? we really dont want a bunch of issues for stuff that isnt made by us. probably best to stick with just suggesting "officially maintained" extensions or customapps, we might then finally be able to migrate the ones in the repo into their own that way too and people can suggest official ones to be added?

@ohitstom I think you misunderstood, but maybe it wasn't that clear in the description either. The goal there is to try to merge marketplace with Spicetify, and maybe even extract it to the "future" Spicetify GUI, so it can better work offline/better deal with jsdelivr being down/blocked.

itsmeow commented 10 months ago

It is absolutely vital that we have a versioning system that matches compatibility of JS, CSS maps, and spicetify hooks to different versions of Spotify. The binary should be able to switch which patch is applied automatically based on the Spotify version installed. From a user perspective, installing ANY (even old) versions of spicetify should automatically pull the correct CSS map and JS for their current version, as well as updating hooks.

To go a step further we could maintain the hooks section of spicetify as a separate thing akin to the css map.

itsmeow commented 10 months ago

Clean css-map and hopefully remake the way it's being fetched from github (latest fetches from master instead of specific version tag)

We did this intentionally, so we don't have to force a release. If you use an older minor version tag, it will use the highest version in that tag OR master if it's the highest already (e.g. 2.24.x, 2.25.x, 2.26.x, master)

'Cleaning it' is also a major undertaking because we don't have the raw data anymore. We would have to write our own spec or find a better way to reverse engineer it than https://github.com/itsmeow/spicetify-css-remapper

rxri commented 10 months ago

It is absolutely vital that we have a versioning system that matches compatibility of JS, CSS maps, and spicetify hooks to different versions of Spotify. The binary should be able to switch which patch is applied automatically based on the Spotify version installed. From a user perspective, installing ANY (even old) versions of spicetify should automatically pull the correct CSS map and JS for their current version, as well as updating hooks.

To go a step further we could maintain the hooks section of spicetify as a separate thing akin to the css map.

That's still to discuss, but yes, I'm aware of this. What I mean by jsHelpers being independent, means that in latest version, they should be updated without the need of spicetify update. I'm thinking of doing the same with hooks however that's a bigger idea

We did this intentionally, so we don't have to force a release. If you use an older minor version tag, it will use the highest version in that tag OR master if it's the highest already (e.g. 2.24.x, 2.25.x, 2.26.x, master)

I agree. I forgot to remove this "suggestion", my bad

ohitstom commented 10 months ago

It is absolutely vital that we have a versioning system that matches compatibility of JS, CSS maps, and spicetify hooks to different versions of Spotify. The binary should be able to switch which patch is applied automatically based on the Spotify version installed. From a user perspective, installing ANY (even old) versions of spicetify should automatically pull the correct CSS map and JS for their current version, as well as updating hooks.

To go a step further we could maintain the hooks section of spicetify as a separate thing akin to the css map.

sounds good in practice, highly doubt we can achieve it to a stable level. we just simply dont have a good enough way of matching xpui to helpers or even an index of spotify releases or xpuis that arent just manually updated which is in no way sustainable.

best you can get is the open sources page on spotifys website that matches xpui to versions but there is no way other than webscraping with github actions to process the data there. doesnt provide downloads too.

i guess what im trying to say is im worried for the future of the project if we start doing a rewrite around the assumption that we will be able to solve this issue when we come to it. i think if we plan to go in said direction we need to focus on that first otherwise it'll become a huge pain later on.

Davoleo commented 9 months ago

Would it be possible to include a version control system for custom-apps/extensions/themes as well?

I don't know if the plan is to integrate it in marketplace completely (even though I've seen it was more or less declined for complexity/security reasons from what I've seen (https://github.com/spicetify/spicetify-marketplace/issues/599)), but for example for custom-apps or extensions installed from this repository we currently have to replace the files manually, and there's nothing that notifies a new version may have been released, so users likely only realize when the feature breaks and you check if it was fixed here in the source code. Again idk how feasible this is, but thought I'd bring it up since one of the main points of the major update is automatic updates.

ohitstom commented 9 months ago

may i add that i think it would be important to create some standardized testing utility for those who want to implement new features or update existing features, if we plan to support from 1.2.0 forward we need some automatic testing that installs all relevant major spotify releases and automatically checks changes made work.

The most important usage would be testing webpack regex between all the versions, could work by storing the output in a text file or something and comparing that the functions seem to be the same across all specified versions?

Currently most PR's lack this kind of testing, so it would be good if we could standardize it outside of just Spicetify.test() - which is pretty inaccurate!

rxri commented 7 months ago

Changing plans. v3 will be a wrapper rewrite with golang codebase cleanup. v4 will be rewritten to Rust v3 will have some stuff planned for rust rewrite ofc:

afonsojramos commented 7 months ago

It would also be good to evaluate other alternatives where we could maintain our golang codebase. Golang is not bad, and allows for faster dev time when compared to Rust. So let's not scratch it off completely. There are numerous ways of building UIs in Go, such as https://github.com/wailsapp/wails. So we should look into that too.

rxri commented 4 months ago

We will probably follow semver at this point starting with v3. Will see but this issue is going to be closed since most of the ideas will be in v3