Add more settings to settings page

istalri commented

2026-06-06 21:05:50 -04:00

Member

This issue is for tracking the settings page development.

For the settings page we need a good balance between intuitive UI/UX, accessibility and familiarity with other matrix clients or chat apps.

As case studies we can look at clients like Cinny, Element and maybe Discord/Telegram and look for the good and bad. Ultimately we want the client to be easily accessible and nice and easy to use. This means we need to think about "sane defaults" and intuitive and findable settings for whatever you may want to change for your use case.

Personally I think crucial features are:

Searchable settings,
Export/Import Settings (probably JSON makes sense) -- good for reinstall or installation on different device,
Account settings: Change Password, Add details (Email etc.), Deactivate
Notification settings.
Long term we should have a lot of accessibility features like:
- adjustable font family(e.g. dyslexic friendly, mono-space) and size,
- monochrome and colorblind friendly themes,
- message spacing settings
- Further accessibility details are documented in #41

Notes:

https://docs.federated.nexus/docs/a8d7e170-2670-43d5-bf71-b46c0b680caf/

This issue is for tracking the settings page development. For the settings page we need a good balance between intuitive UI/UX, accessibility and familiarity with other matrix clients or chat apps. As case studies we can look at clients like Cinny, Element and maybe Discord/Telegram and look for the good and bad. Ultimately we want the client to be easily accessible and nice and easy to use. This means we need to think about "sane defaults" and intuitive and findable settings for whatever you may want to change for your use case. Personally I think crucial features are: - Searchable settings, - Export/Import Settings (probably JSON makes sense) -- good for reinstall or installation on different device, - Account settings: Change Password, Add details (Email etc.), Deactivate - Notification settings. - Long term we should have a lot of accessibility features like: - adjustable font family(e.g. dyslexic friendly, mono-space) and size, - monochrome and colorblind friendly themes, - message spacing settings - Further accessibility details are documented in #41 ### Notes: https://docs.federated.nexus/docs/a8d7e170-2670-43d5-bf71-b46c0b680caf/

Henry-Hiles changed title from ~~Settings Page Development~~ to Settings Page

2026-06-09 20:40:56 -04:00

Henry-Hiles self-assigned this

2026-06-11 15:59:40 -04:00

istalri was assigned by Henry-Hiles

2026-06-11 15:59:40 -04:00

Henry-Hiles commented

2026-06-11 16:14:49 -04:00

Owner

Going to just write down the way this works in my mind:

We have a IMap<String, IList<Setting>> to describe the settings page, where the String is a category name, and each Setting is a class with: Widget widget, String name, String description, for searching.

Then, on mobile, these will be shown as buttons, each one pushing a page of widgets for that category.

On desktop, categories will be a sidebar, and the main pane will show the widgets for that category.

For search, we can have a search icon that pushes a page that searches all settings' descriptions and names for a match, and shows specifically those widgets in a listview.

Going to just write down the way this works in my mind: We have a `IMap<String, IList<Setting>>` to describe the settings page, where the String is a category name, and each Setting is a class with: `Widget widget, String name, String description`, for searching. Then, on mobile, these will be shown as buttons, each one pushing a page of widgets for that category. On desktop, categories will be a sidebar, and the main pane will show the widgets for that category. For search, we can have a search icon that pushes a page that searches all settings' descriptions and names for a match, and shows specifically those widgets in a listview.

👍 1

Henry-Hiles commented

2026-06-11 16:17:05 -04:00

Owner

For actually storing the client settings, we have two main choices:

Shared Preferences:
- Pros:
  - Easy
  - Works on every platform out of the box
  - We already use shared prefs for other things
- Cons:
  - Both settings and data like last selected room would be stored in sharedprefs
  - Can't be declaritively set, if someone wants to configure nexus with e.g. nixos
Json File
- Pros:
  - Not too hard
  - Should work on every platform with minimal code, just need to figure out where to put the file.
  - Can be declaratively configured
- Cons:
  - Requires more platform-specific code

For actually storing the client settings, we have two main choices: - Shared Preferences: - Pros: - Easy - Works on every platform out of the box - We already use shared prefs for other things - Cons: - Both settings and data like last selected room would be stored in sharedprefs - Can't be declaritively set, if someone wants to configure nexus with e.g. nixos - Json File - Pros: - Not too hard - Should work on every platform with minimal code, just need to figure out where to put the file. - Can be declaratively configured - Cons: - Requires more platform-specific code

👍 1

istalri commented

2026-06-12 04:15:51 -04:00

Author

Member

@Henry-Hiles wrote in #37 (comment):

For actually storing the client settings, we have two main choices:

* Shared Preferences:
  
  * Pros:
    
    * Easy
    * Works on every platform out of the box
    * We already use shared prefs for other things
  * Cons:
    
    * Both settings and data like last selected room would be stored in sharedprefs
    * Can't be declaritively set, if someone wants to configure nexus with e.g. nixos

* Json File
  
  * Pros:
    
    * Not too hard
    * Should work on every platform with minimal code, just need to figure out where to put the file.
    * Can be declaratively configured
  * Cons:
    
    * Requires more platform-specific code'

I think long term JSON is better for multiple reasons:
- Easy to export as it is just a file.
- Easy to import, just swap existing JSON-File with new one in one go.
- More flexibility, in case we ever need it. (like nested structures.)
- Same underlying structure for settings on all systems.
- JSON is widely adopted/easy to read and use
- JSON-Serializer is build in into dart

If we want to make it easy we could just use Shared Preferences to safe a JSON String, but I think https://pub.dev/packages/path_provider would be a good option meaning we would technically have no platform specific code we would have to write ourselves. (Although we could if we wanted.)

@Henry-Hiles What do you think?

@Henry-Hiles wrote in https://git.federated.nexus/Nexus/nexus/issues/37#issuecomment-350: > For actually storing the client settings, we have two main choices: > > * Shared Preferences: > > * Pros: > > * Easy > * Works on every platform out of the box > * We already use shared prefs for other things > * Cons: > > * Both settings and data like last selected room would be stored in sharedprefs > * Can't be declaritively set, if someone wants to configure nexus with e.g. nixos > > * Json File > > * Pros: > > * Not too hard > * Should work on every platform with minimal code, just need to figure out where to put the file. > * Can be declaratively configured > * Cons: > > * Requires more platform-specific code' I think long term JSON is better for multiple reasons: - Easy to export as it is just a file. - Easy to import, just swap existing JSON-File with new one in one go. - More flexibility, in case we ever need it. (like nested structures.) - Same underlying structure for settings on all systems. - JSON is widely adopted/easy to read and use - JSON-Serializer is build in into dart If we want to make it easy we could just use Shared Preferences to safe a JSON String, but I think https://pub.dev/packages/path_provider would be a good option meaning we would technically have no platform specific code we would have to write ourselves. (Although we could if we wanted.) @Henry-Hiles What do you think?

Henry-Hiles commented

2026-06-12 09:15:57 -04:00

Owner

Yes, we already use path_provider, so we would use that to find the path.

Yes, we already use `path_provider`, so we would use that to find the path.

👍 1

Henry-Hiles referenced this issue from a pull request that will close it,

2026-06-23 22:37:25 -04:00

Add settings page #46

Henry-Hiles closed this issue

2026-07-17 20:36:43 -04:00

Henry-Hiles referenced this issue from a commit

2026-07-17 20:36:43 -04:00

Add settings page (#46)

Henry-Hiles changed title from ~~Settings Page~~ to Add more settings to settings page

2026-07-17 20:46:35 -04:00

Henry-Hiles reopened this issue

2026-07-17 20:46:40 -04:00

Henry-Hiles commented

2026-07-17 20:47:14 -04:00

Owner

A settings page was implemented, but I'm reopening this to track adding more settings, as right now we only have a couple.

🎉 1

Henry-Hiles commented

2026-07-17 20:49:40 -04:00

Owner

Files of interest:

lib/controllers/settings_sections_controller.dart: Describes each setting in the UI: title, description, icon, etc.
lib/models/settings.dart: Describes each setting in the config file, and the defaults.
These two should be all thats needed to be modified for more settings :)

Files of interest: - `lib/controllers/settings_sections_controller.dart`: Describes each setting in the UI: title, description, icon, etc. - `lib/models/settings.dart`: Describes each setting in the config file, and the defaults. These two should be all thats needed to be modified for more settings :)

👍 1

Rows
Columns

Add more settings to settings page #37

Notes: