feat: add configurable panel width for Titles style

[topik]

Summary

Adds configurable panel width for the Titles appearance style to address the issue mentioned in #3882 where the UI becomes too wide on ultrawide monitors.

Changes

• Add automatic width optimization based on screen aspect ratio:
  • 30% for super ultrawide displays (32:9, e.g., 5120×1440)
  • 45% for regular ultrawide displays (21:9, e.g., 3440×1440)
  • 60% for standard displays (unchanged from current behavior)
  • 80% for vertical displays (unchanged)
• Add user-configurable custom width option with slider (10-90%)
• Add "Panel width" setting in "Customize Titles style" with Automatic/Custom modes
• Add isUltrawide() and isSuperUltrawide() helper functions to NSScreen

Testing

Tested on 5120×1440 (32:9) display where automatic mode correctly applies 30% width. Also verified on standard 16:9 display to ensure backwards compatibility. Custom slider works as expected and preferences persist correctly.

Implementation Notes

The two-tier approach keeps absolute panel widths similar across screen types (~1500-1600px) while preventing the UI from being overwhelming on super ultrawide displays. Existing users on standard displays won't see any changes.

Preview

Edit: Forgot to include settings UI

[lwouis]

Hi,

Thank you for sharing this PR! I haven't had time to review it yet. I finally got things running again on my machine, and could work on the backlog. Reviewing this PR is next on my list 👍

Thank you

[lwouis]

I have played with the PR. I have a few questions and remarks 👍

• There is already a mecanism for automatically setting the width of the AltTab window:

  alt-tab-macos/src/logic/AppearanceTestable.swift

  Line 12 in 122dc2e

  static func comfortableWidth(_ physicalWidth: Double?) -> Double {

  . It seems you re-implemented it with a new logic of discrete ratios, versus the existing fluid logic. I think this is a big redundant. It would be better to reuse the existing system, and perhaps tweak the numbers for Titles Appearance
• Regarding the manual width slider, I'm not a fan of this. We used to have many sliders for all the settings. Then with v7, we simplified a lot. That meant removing customization away, in order to improve the UX for most users. So I don't think we should go the slider route. It's a regression in a way. In addition, there have been discussions of having a set width, instead of percent width. This would help users with multiple screens, it seems. See conversations in #v7 and Window max/min width in a row: provide alternative for ultrawide monitors #1506

What do you think?

Thank you

[topik]

Good point. Simplified the PR:

• Reuses comfortableWidth() instead of re-implementing
• Applies multiplier for ultrawides only
• No sliders/preferences

Works well on my 32:9 screen now. I don't think it's necessary to change width for Thumbnails or App Icons. Titles are specific because reading text spread across 3000+ pixels feels awkward on super ultrawides. The PR only adjusts Titles for (super)wide screens and doesn't change anything else.

Quick comparison

Screen	Aspect Ratio	Final Width	Notes
Super ultrawide	≥3.0 (32:9)	~30-33%	Uses comfortableWidth × 0.65, min 30%
Regular ultrawide	2.3-3.0 (21:9)	~45-64%	Uses comfortableWidth × 0.85, min 45%
Normal screens	<2.3 (16:9, etc)	60% horizontal, 80% vertical	Unchanged from original

The multipliers respect physical screen size (via comfortableWidth) while keeping text readable on ultrawides.

Is this acceptable?

[lwouis]

Thank you @topik

Reading your rationale, and looking at the code, the following thought comes to my mind.

Your goal is readability of the Titles Appearance on wide screens. The PR proposes to add a second layer of width calculation. It comes after the comfortable width is set. It reduces it in special cases.

Comfortable width should be comfortable. So why is it not currently? I think it's because it focuses on field-of-view. The AltTab window is scaled for a comfortable viewing experience. However, with Titles Appearance, there is an added topic for comfort: line length. This is not included today.

I think line-length should be addressed specifically. A common rule-of-thumb, used for latin-language books for example, is ~65 characters.

Thus here is my proposal: instead of adding arbitrary ratios to reduce the width, we instead look at font-size, calculate the width of 65 characters, then use the min(comfortableWidth, 65chars). This guarantees that the panel is both confortable in regards to field-of-view and line-length.

What do you think?

Interestingly, many people have asked if we could have the Titles Apperance be more compact. That is: if its width could be the width of the longuest title. To avoid having lots of empty space. This is discussed in #3882. Depending on how we measure line-length here, we could do 2 birds with 1 stone, and set the width to min(comfortableWidth, 65chars, widestRow)

[topik]

The character-width approach is outside the scope of what I'm trying to fix. The multiplier solution reuses comfortableWidth() like you suggested in your first review. If that's not good enough, feel free to close this. I'm not taking it further 🙂