unify behavior of preference options

[mixxxbot]

Reported by: rryan
Date: 2014-04-17T16:04:49Z
Status: In Progress
Importance: Low
Launchpad Issue: lp1309089
Tags: polish, preferences, usability

---

We have a huge variety of inconsistency in the preference pages. There are 4 main events the preference pages get and currently every page treats them differently.

• Update (load the latest config settings into the GUI widgets)
• Apply (take the GUI widget settings and write them to the user config, live COs)
• Cancel (take changes since last Update and revert them)
• Reset to defaults (reset the GUI widgets to default values, then call Apply to write them to the config)
• Show (the preferences dialog is shown to the user)
• Hide (the preferences dialog is hidden from the user)

• When the user opens preferences, a Show and Update event is delivered to every page.
• When the user hits Apply, an Apply event is delivered to the current page.
• When the user hits OK, an Apply and Hide event is delivered to every page.
• When the user hits Reset, a Reset event is delivered to the current page.

The GUI widgets themselves are also quite inconsistent on whether they trigger updates if a user changes the widget or if code changes the widget. Code changing the widget triggering slots can lead to circularity and so all widgets should only trigger slots if a user changes them, not if code does.

All the pages do different things on update and apply. Some of them update widgets and config/COs on update, some of them update widgets only but because widgets trigger on code changes, that also updates the config and live COs. It's a big mess.

We also need to track dirty state uniformly across all pages. That way we can enable or disable the apply button if the page is clean.

[mixxxbot]

Commented by: ronso0
Date: 2022-04-13T22:11:30Z

---

... and warn when leaving a page with pending changes.

[mixxxbot]

Commented by: ronso0
Date: 2022-04-13T22:19:17Z

---

a few PRs trying to unify the behaviour:
#4721
#4667

[ronso0]

one step further: #11527