KittyCAD / modeling-app

The KittyCAD modeling app.
https://kittycad.io/modeling-app/download
MIT License
420 stars 35 forks source link

separate user specific project settings from stuff you want in git #3961

Open jessfraz opened 1 month ago

jessfraz commented 1 month ago

we should split units setting out of project.toml and because you want to commit your units to git but you don’t wanna commit your theme etc. so we need two files. Settings for stuff that you want in git and user specific shit

And you can presume for assemblies we’d want dependencies in the same file as units

lf94 commented 1 month ago

What should we call this new file? environment.toml or?...

jessfraz commented 1 month ago

whatever you think, kurt mentioned vscode uses .vscode for user specific stuff i think making a dot file helps

jessfraz commented 1 month ago

and the one commited to git would not be a dot file

lf94 commented 1 month ago

Oh shit I like that. zma.toml, kcl.toml. Yes yes yes...

franknoirot commented 1 month ago

Okay I've been taking a look at the settings as understood by both Rust and TS sides, here are my notes:

Notes

Settings according to TS

Settings that need to be in version control

Settings that don't need to be in version control, but should be able to be per-project

Settings that are useful to the CLI

Basically anything that affects the stream appearance, which in turn impacts the configuration for the zoo kcl snapshot command:

Recommendations

  1. use the term "preferences" for non-critical, and therefore not-tracked-by-default, settings
  2. rename the user preferences file to user.toml, since it would now contain settings and preferences
  3. for user level, move all preferences into a different namespace in user.toml, under preferences
  4. for project-level, split the current project.toml into settings.toml and .preferences.toml
    • Since the only project-level preference I see is themeColor, I think we could forego this if we want
  5. update TS side to use structure defined in Rust side, such as app.appearance preference category
  6. consider grouping CLI-necessary preferences
  7. add backwards compatibility to read from the way things are, but never write to it

There are a lot of UI implications to this, which I think is working through in its own issue.