feat: Project-specific Editor Settings

[malec-palec]

Adds support for per-project editor preferences via settings.ini file.

Features

• Read settings.ini from project root when opening a project
• Apply settings to override editor preferences (previews, scene editor, etc.)
• Uses ini npm library for robust INI parsing
• Works only in Electron (desktop) version

Usage

Place a settings.ini in the project root:

autosaveOnPreview = true
use3DEditor = false
showDeprecatedInstructionWarning = true

Supported Settings

• Preview settings (autosaveOnPreview, takeScreenshotOnPreview, etc.)
• Scene editor (use3DEditor, showBasicProfilingCounters)
• Other (showExperimentalExtensions, showDeprecatedInstructionWarning, etc.)

See newIDE/docs/Project-Settings.md for the full list.

[4ian]

Hi!

Thanks for opening this PR.
"ini" file format is a bit old. What do you think of using YAML instead? A few key things I see:

• It "looks good", can be written by a human.
• It's a superset of JSON.
• It is fairly popular in other tools (CI configuration files, etc...)

As for the implementation, my main thinking is:

• I think it's interesting :)
• We could even extend this to the web-app in the future by storing this somehow. (not mandatory for now)
• We should think about reducing the implementation by maybe having a whitelisted list of property names that can be overriden? I'll make a comment about this.

[4ian]

This is fairly verbose. I wonder if we could reduce everything to a few key concepts:

• ProjectSettings renamed to "ProjectSpecificPreferences". It can be a "Partial" (or in Flow, I think it's $Shape<Preferences>).
• An "allowlist" of names of preferences that can be overwritten.
• When a project is loaded, preferences are loaded from it and applied without needing to code the calls to the setters.

This would reduce this function to something that iterates on the allowlist.

[4ian]

The allowlist is basically what you called "VALID_PREFERENCE_KEYS"

[4ian]

These tests are a bit of a "tautology". I would rather reduce the noise-to-signal ratio by not having them, as "testing a Set" is not super interesting and will actually make the codebase less flexible (because you have to remember updating these if at some point you rework the set to be something else). In other words, the Set is not really something I would expose to the "outside world".

I think the only test that would be worth having is one that the content from a file (Yaml file maybe, as discussed in my other comment) is properly applied to preferences.