✨ Refactor Preferences to use new Ventura-style Settings style

[austincondiff]

Describe the solution you'd like

Now that we have a minimum target of macOS 13.0, we should be using the new Settings appearance introduced in macOS 13.0. This is how this might look

Scope

• Modify the current Preferences window with the top tabs to be a Settings window with a sidebar listing all items on the left.
• Convert existing Preferences views to new Settings views.
• Use mock data if some data is not available.
• Disable non-functional items.

Mockups

Please note: these mockups are just a concept and go far beyond the scope of this issue which is to convert what is already there. The remainder will be accounted for in future issues.

[cryptoAlgorithm]

Hi, this issue looks good and I'd like to pick it up.

[austincondiff]

@cryptoAlgorithm Thank you. I just assigned it to you. Please let me know if you have any questions.

[matthijseikelenboom]

I must say that I think that this issue is way too big. It's more an epic then an issue/ticket. Now it's also the responsibility of the one person who is working on it.

I think it should be split up in smaller issues or tasks. Perhaps also a "new-settings" branch for faster iterative development. That way multiple people could be working on it at the same time, provided that there is good communication.

I would split it in building a fundamental window first, then others can join to add tabs to that window. Also @Wouter01 mentioned in the Discord he wants to rework the way we want to store settings, that can also be done on that branch to that branch. If we decide to do that of course.

[cryptoAlgorithm]

@matthijseikelenboom Thanks for voicing your concerns! I'll be implementing mainly a skeleton UI, basically with placeholder data for most of the settings UI (to match the mockups as closely as possible).

Someone could continue the effort after I'm done with the skeleton UI, as I'm not familiar with how we intend to handle persisting Settings going forward.

[austincondiff]

@matthijseikelenboom as I mentioned…

Please note: these mockups are just a concept and go far beyond the scope of this issue which is to convert what is already there. The remainder will be accounted for in future issues.

Maybe I should have been more specific on what is expected besides “convert what is already there”.

If that is still too big, should I break this up into separate issues by Settings section?

[cryptoAlgorithm]

@austincondiff, no, i think this issue is good as is. However, it may be prudent to consider adding a disambiguation regarding the scope of this issue, and how we plan to tackle it (i.e. just migrating existing views and using mock data for the rest).

[austincondiff]

@cryptoAlgorithm I just added a Scope section to the issue description. Let me know if it needs adjustment.

[matthijseikelenboom]

@austincondiff It depends, if PreferencesSection and PreferencesContent refactor automatically fix the whole UI for every section, then it's fine I guess. Otherwise, yes, it should be broken up in subtasks in this issue or new issues if you ask me. I'd suggest to at least make every section a separate PR. So a PR for General, a PR for Accounts, a PR for Behavior etc etc.

[Wouter01]

I'd try to stick to Section as most as possible, and remove the PreferencesSection alltogether. Also, does it make sense to create views for settings that don't exist yet? Most of the time, it's extra work to go ahead and modify existing views to remove the mock data and apply a new data structure. I think it might be better to just stick to an "implementation needed" screen

[cryptoAlgorithm]

@Wouter01 Good point, maybe I'll just work on the sidebar first and we can think of what to do with the content later on.

[aheze]

Setting could help - https://github.com/aheze/Setting

Lets you build settings with a @ViewBuilder-like syntax. Currently not great on macOS but I'll make it a priority.

[austincondiff]

@aheze we discussed this on Discord. @Wouter01 even threw together a POC and it was definitely not worth using for our uses.