feat(macos): `title_bar_style` and `hidden_title` window options, closes #2663

[probablykasper]

What kind of change does this PR introduce?

• [ ] Bugfix
• [x] Feature
• [ ] Docs
• [ ] New Binding issue #___
• [ ] Code style update
• [ ] Refactor
• [ ] Build-related changes
• [ ] Other, please describe:

Does this PR introduce a breaking change?

• [ ] Yes, and the changes were approved in issue #___
• [x] No

Checklist

• [x] When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• [x] A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• [x] I have added a convincing reason for adding this feature, if necessary

Other information

I assume this needs to wait for v2

[probablykasper]

These APIs existed when tao was being audited so if it is really a high demand feature, we can maybe include it?

It is the most upvoted issue, so it sure does have demand

[xuchaoqian]

These APIs existed when tao was being audited so if it is really a high demand feature, we can maybe include it?

Yes, it is really a high demand feature. Lots of apps need to customize title bar. This is a very useful and basic feature for them.

[betamos]

I use this in my Tauri fork. I love it.

Some thoughts on the feature itself:

• It's much preferable to use real window chroming than faking it with browser markup, especially for MacOS:
  • Alt-button works and changes the meaning of buttons.
  • Hovering gives me menus of moving window to the side/different screen, etc.
  • Traffic lights tone out to gray when window is blurred.
  • Whenever the OS vendor changes their UI, the app won't look outdated.
• Details matter. Just like how we want the Tauri website to look professional and modern, many designers, devs and users care about those same things. TL;DR: I think it's worth prioritizing.
• Dragging the app can become less intuitive without title bar and it's important to consider from a UX perspective. I solved it by making all non-interactive elements draggable (here's how). This improves UX also on other platforms.

Some technical thoughts:

• You are likely to want to want minor MacOS CSS tweaks due to the visual differences of the title bar:
  • Platform CSS media-queries don't work that well, so...
  • You have to check platform through tauri.os.platform() and change the CSS that way
  • [untested] Use small/large viewport units in your CSS.
• The fullsize_content_view param does not appear to have any effect. I have both transparent_titlebar and hidden_title turned on.
• I think the enum API would be better than booleans. It's easier to document and takes up shorter space. It also prevents invalid/ineffective combinations of the underlying booleans.

[probablykasper]

I'm not sure if going the TitleBarStyle enum route is ideal. There are a few different situations to cover:

• Showing the title bar
• Transparent titlebar with fullsize content view. This allows you to put html under the titlebar.
• Transparent titlebar without fullsize content view. This gives you a different look without needing to worry about different OS versions having different title bar heights and you don't run into https://github.com/tauri-apps/tauri/issues/4316

None of the above "hide" the titlebar, because the title and traffic lights can still be visible. In fact, in tao (and Xcode storyboards), hiding the titlebar

• hides the traffic lights
• disables the window border
• disables rounded window corners

[probablykasper]

Went with this:

enum TitleBarStyle {
  Visible,
  Transparent,
  Hidden,
}

[JonasKruckenberg]

I solved it by making all non-interactive elements draggable

You mean all elements within the titlebar?

Went with this:

enum TitleBarStyle {
 Visible,
 Transparent,
 Hidden,
}

I like this 👍

[betamos]

You mean all elements within the titlebar?

No, everywhere in the window. I've seen it on some apps in the wild and it's great. Works for people that assume you have to drag from top too, so no learning curve, and no other downsides afaik.

[probablykasper]

I like this 👍

@JonasKruckenberg Sorry, this is actually what I went with:

enum TitleBarStyle {
Visible,
Transparent,
Overlay,
}

The reasoning is what I explained above

[xuchaoqian]

Can we merge this PR? Many people are waiting for this feature...

[gradddev]

Waiting this feature too...

[p0ryae]

Looking forward to the merge. This feature is highly in demand with people.

[lucasfernog]

Looks good to me, but I'm not seeing any differences with the Transparent mode (though Overlay looks amazing!) @probablykasper