You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
✨ Refactor Preferences to use new Ventura-style Settings style #1066
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.
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.
@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.
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?
@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 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.
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
changed the title [-]✨ Preferences to use Ventura-style Settings[/-][+]✨ Refactor Preferences to use new Ventura-style Settings style[/+]on Apr 1, 2023
Activity
[-]✨ Move Preferences to use Ventura-style Settings[/-][+]✨ Preferences to use Ventura-style Settings[/+]cryptoAlgorithm commentedon Feb 22, 2023
Hi, this issue looks good and I'd like to pick it up.
austincondiff commentedon Feb 22, 2023
@cryptoAlgorithm Thank you. I just assigned it to you. Please let me know if you have any questions.
matthijseikelenboom commentedon Feb 22, 2023
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 commentedon Feb 22, 2023
@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 commentedon Feb 22, 2023
@matthijseikelenboom as I mentioned…
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 commentedon Feb 22, 2023
@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 commentedon Feb 22, 2023
@cryptoAlgorithm I just added a Scope section to the issue description. Let me know if it needs adjustment.
matthijseikelenboom commentedon Feb 22, 2023
@austincondiff It depends, if
PreferencesSectionandPreferencesContentrefactor 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 forGeneral, a PR forAccounts, a PR forBehavioretc etc.Wouter01 commentedon Feb 22, 2023
I'd try to stick to
Sectionas most as possible, and remove thePreferencesSectionalltogether. 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" screencryptoAlgorithm commentedon Feb 26, 2023
@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 commentedon Feb 26, 2023
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 commentedon Feb 26, 2023
@aheze we discussed this on Discord. @Wouter01 even threw together a POC and it was definitely not worth using for our uses.
[-]✨ Preferences to use Ventura-style Settings[/-][+]✨ Refactor Preferences to use new Ventura-style Settings style[/+]