Preferences on macOS are now called Settings

[foss-]

Feature Description

Adapt new Apple terminology. In macOS 13 Ventura they renamed System Preferences to System Settings and followed up on that change with all apps renaming Preferences to Settings.

Mixxx should follow that change as well for macOS and rename menu bar > Mixxx > Preferences… to Settings…

[luzpaz]

should be labeled with macOS tag

[ronso0]

So someone translated Preferences > Settings on Transifex which caused the issue reported here #11670 (comment) ?

[m0dB]

I don't think the issue is translation related. The problem comes from QActions &Preferences and &Settings referring to the same internally in Qt.

[m0dB]

In fact , this is what happens:

From Qt docs on QAction menuRole:

"This indicates what role the action serves in the application menu on macOS. By default all actions have the TextHeuristicRole, which means that the action is added based on its text (see QMenuBar for more information)."

So, these text heuristics assign the role PreferenceRole to both.

[m0dB]

Fixed now by changing the menu role in #11679

[ronso0]

Thanks for clarifying @m0dB

So is this issue solved by TextHeuristicRole and Settings is now in the app menu, or do we now have two different actions calling the same slot, Settings in the app menu and Preferences in the Options menu?

[foss-]

Tested in 2.5-alpha-53-g5f22560dce (main)

menubar item looks good:

There is a remaining problem for the Settings window itself which currently still shows Preferences as title. Two solutions come to mind:

• also change naming from Preferences to Settings
• follow macOS hig and change window title to reflect currently visible pane as per https://developer.apple.com/design/human-interface-guidelines/settings#macOS
  

[JoergAtGithub]

How could we handle different terms in the manual?

[ronso0]

The Mixxx manual refers to "Preferences", so we have an incositency (on macOS) either way:
app menu item name vs. window title, or both vs manual term.
Changing Preferences to Settings everywhere in the manual (for all OS) just because Apple did so feels...

follow macOS hig and change window title to reflect currently visible pane as per https://developer.apple.com/design/human-interface-guidelines/settings#macOS

changing the window title per pane would be nice, but is indepent because it doesn't solve the inconsstency described above.

[foss-]

Have to admit, I had not thought about documentation. Probably fair to stick with Preferences for the manual to keep things simple.

[Swiftb0y]

Maybe just add a disclaimer for macOS users to the mental translation themselves?

[m0dB]

By setting the menuRole to QAction::PreferencesRole, the menu item text is set to either "Settings" or "Preferences", depending on the version of macOS. This is independent of the title that is passed to the QAction constructor (which is completely ignored). I am on Monterey and here it's still Preferences.

Now, for the Dialog title:

According to Apple's Human Interface Guidelines, the title of the dialog should actually be neither Preferences nor Settings! See https://developer.apple.com/design/human-interface-guidelines/patterns/settings/ which reads:

Update the window’s title to reflect the currently visible pane. If your settings window doesn’t have multiple panes, use the title App Name Settings.

As we do have multiple panes (or tabs if you will), we would set the title to the selected tab (e.g. Sound hardware, Library, etc). That way we kill two birds with one stone: we don't have to worry about a inconsistency between the menu item and the dialog title, and we integrate more correctly in the host OS.

If we don't want to go that route, I have some obj-c code that programmatically determines the title of the actual application menu's Settings / Preferences menu item . We could use this to set the title of the Settings / Preferences dialog so it matches.

And finally we could forget about the whole ordeal, and force the use of Preferences instead of Settings independent of the version of macOS. This is explained here: https://lapcatsoftware.com/articles/Preferences.html

My personal preference would be setting the title to the selected tab, for the reasons above but also because it is trivial, and only requires Qt/c++ code.

As for the manual, I think that a simple disclaimer would do the trick. Something along the lines of:

"On macOS Ventura and later, the "Preferences..." application menu item has been changed to "Settings...". Note that this documentation still refers to Preferences."

(But frankly, I'm sure that all macOS Ventura users are aware of this change)

[m0dB]

PR created: #11696

[foss-]

With #11696 merged this issue is resolved. Closing.

Thanks so much for going the extra mile and implementing the very nice solution of showing the active tap in dialog title bar @m0dB .