Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change window title to Preference Pane title #15

Closed
2 tasks done
DivineDominion opened this issue Apr 3, 2019 · 9 comments · Fixed by #19
Closed
2 tasks done

Change window title to Preference Pane title #15

DivineDominion opened this issue Apr 3, 2019 · 9 comments · Fixed by #19

Comments

@DivineDominion
Copy link
Collaborator

DivineDominion commented Apr 3, 2019

Found this advice in the HIG today: https://developer.apple.com/design/human-interface-guidelines/macos/app-architecture/preferences/

So maybe after #6 is merged,

  • rename PreferencePane.toolbarTitle to simply title or preferencePaneTitle
  • use the title for the window title

This also makes #12 obsolete.

@sindresorhus
Copy link
Owner

I have seen it, but I have intentionally ignored it. I personally don't think it makes much sense to repeat the tab title in the window title. It's already clear which tab it's on. I was kinda hoping no one would notice 😝 Also, a lot of Apple's apps and even macOS don't follow the HIG entirely.

But I guess we should do this to follow the HIG...

@sindresorhus
Copy link
Owner

Update the window's title to reflect the currently visible preference pane. For example, if your preferences window has a General preference pane, the window’s title should be General when that pane is active.

This makes the window title unusably generic in the window list. It will just show "General", which does not make it clear that the window is a preference window...

@sindresorhus
Copy link
Owner

We also need to take into account this:

If your window doesn’t have multiple preference panes, then its title should be App Name Preferences.

@sindresorhus
Copy link
Owner

Some observations:

  • Finder.app shows "Finder Preferences" as the window title for all the panes.
    Which is a violation of:

    Update the window's title to reflect the currently visible preference pane.

  • Messages.app has the minimize button enabled.
    Which is a violation of:

    Disable the Minimize and Zoom buttons.

  • Mail.app has the minimize button enabled.
    Which is a violation of:

    Disable the Minimize and Zoom buttons.

  • iTunes.app doesn't apply the changes immediately.
    Which is a violation of:

    Apply preference changes immediately.

  • Dictionary.app has the zoom button enabled.
    Which is a violation of:

    Disable the Minimize and Zoom buttons.

  • Books.app uses the tab title and the word "Preferences" as the window title, for example, "General Preferences".
    Which is a violation of:

    For example, if your preferences window has a General preference pane, the window’s title should be General when that pane is active.

  • TextEdit.app uses the window title "Preferences".
    Which is a violation of:

    If your window doesn’t have multiple preference panes, then its title should be App Name Preferences.

  • FaceTime.app uses the window title "Preferences".
    Which is a violation of:

    If your window doesn’t have multiple preference panes, then its title should be App Name Preferences.

  • Keychain Access.app uses the window title "Preferences".
    Which is a violation of:

    If your window doesn’t have multiple preference panes, then its title should be App Name Preferences.

  • Script Editor.app has the minimize button enabled.
    Which is a violation of:

    Disable the Minimize and Zoom buttons.

  • Audio MIDI Setup.app has the minimize and zoom button enabled.
    Which is a violation of:

    Disable the Minimize and Zoom buttons.

Xcode.app shows the tab as the window title, but then modifies the "Window" menu to show "Preferences - General", admitting that the tab title is not clear enough of a window title.

Apple, as usual, has such a double standard. They expect third-party apps to follow their HIG, but they couldn't care less to follow it themselves.

I have filed a Radar: https://openradar.appspot.com/radar?id=5029274855669760

@DivineDominion
Copy link
Collaborator Author

Wow, good detective work :) I wonder what their response is going to be.

I actually like how Xcode prepends "Preferences - " to the window title list best, just to add my 2¢.

@sindresorhus
Copy link
Owner

sindresorhus commented Apr 3, 2019

I actually like how Xcode prepends "Preferences - " to the window title list best, just to add my 2¢.

Me too.


I wonder what their response is going to be.

As with 95% of my the radars I submit, probably none...


Should we rename toolbarItemTitle to preferencePaneTitle now that we'll use it for both the toolbar item and the window title? Kinda makes sense, since it's not really a "toolbar item" when using the segmented controls.

@DivineDominion
Copy link
Collaborator Author

DivineDominion commented Apr 4, 2019

I didn't find a way to implement the nice addition of Preferences -- to the window list title. I am afraid this is a menu customization. We could offer a drop-in controller/service object that people tie to their window menu and that (1) removes the preference window from the regular window list, and (2) adds it as a custom entry above the regular list.

After all, Xcode's window list does look different from e.g. Finder's:

Screenshot 2019-04-04 at 08 52 12 Screenshot 2019-04-04 at 08 52 20

That's a strong indicator for me that they replaced the system default functionality.

Or we set the window title to "Preferences -- \(preferencePaneTitle)" and replace the titlebar's label with a custom one that drops the prefix.

@sindresorhus
Copy link
Owner

Or we set the window title to "Preferences -- (preferencePaneTitle)" and replace the titlebar's label with a custom one that drops the prefix.

That actually makes more sense, as you would want to improved title in the window list and mission control too. But I think we should think about the problem a little bit more before implementing this, and it should obviously be opt-in.

@DivineDominion
Copy link
Collaborator Author

Inspecting Xcode windows, it actually does not use the Preferences -- prefix in the actual window title. Folks in a Slack proposed changes during menu validations.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants