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

wrong window title/tab bar on macos, nightly #4966

Closed
daviehh opened this issue Feb 5, 2024 · 8 comments
Closed

wrong window title/tab bar on macos, nightly #4966

daviehh opened this issue Feb 5, 2024 · 8 comments
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. macOS Issue applies to Apple macOS

Comments

@daviehh
Copy link

daviehh commented Feb 5, 2024

What Operating System(s) are you seeing this problem on?

macOS

Which Wayland compositor or X11 Window manager(s) are you using?

No response

WezTerm version

20240205-070437-39d2b6ca aarch64-apple-darwin

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

Yes, and I updated the version box above to show the version of the nightly that I tried

Describe the bug

Launch wezterm with window_decorations = "INTEGRATED_BUTTONS|RESIZE" and a custom font, the window title bar/ tab bar would be incorrectly displayed, see below:
Screenshot 2024-02-05 at 3 32 20 PM

To Reproduce

launch wezterm.app

Configuration

local wezterm = require 'wezterm'

-- This table will hold the configuration.
local config = {}

if wezterm.config_builder then
	config = wezterm.config_builder()
end

config.font = wezterm.font 'MonaspiceNe Nerd Font Mono'
config.window_decorations = 'INTEGRATED_BUTTONS|RESIZE'

return config

Expected Behavior

correct window title/tab bar

Logs

Debug Overlay
wezterm version: 20240205-070437-39d2b6ca aarch64-apple-darwin
Window Environment: macOS 14.3 (23D56)
Lua Version: Lua 5.4
OpenGL: Apple M1 Pro 4.1 Metal - 88
Enter lua statements or expressions and hit Enter.
Press ESC or CTRL-D to exit
15:31:49.028 INFO wezterm_gui::termwindow > QuitApplication over here (window)

Anything else?

No response

@daviehh daviehh added the bug Something isn't working label Feb 5, 2024
@wez wez added the macOS Issue applies to Apple macOS label Feb 5, 2024
@wez
Copy link
Owner

wez commented Feb 6, 2024

I can't reproduce this. Is there more to your config file?

@wez wez added cant-reproduce The issue cannot be reproduced as described waiting-on-op Waiting for more information from the original poster labels Feb 6, 2024
@daviehh
Copy link
Author

daviehh commented Feb 6, 2024

No, that's the whole config file. It's only upon first launch, tab bar shows correctly after resizing the window or moving to external monitor.

@github-actions github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Feb 6, 2024
@wez
Copy link
Owner

wez commented Feb 6, 2024

I didn't source and install the font you mentioned, because the wezterm.font line shouldn't influence the fancy tab bar.
If you comment out the wezterm.font line, does that change things?

@wez wez added the waiting-on-op Waiting for more information from the original poster label Feb 6, 2024
@wez
Copy link
Owner

wez commented Feb 6, 2024

Do you have other window management software installed that might adjust the size or layout of windows?

@daviehh
Copy link
Author

daviehh commented Feb 6, 2024

Thanks, no window manger, but the font line is necessary for the issue to appear.
With macos built-in fonts, config.font = wezterm.font 'Monaco' produces the issue while the font Menlo appears fine

@github-actions github-actions bot removed the waiting-on-op Waiting for more information from the original poster label Feb 6, 2024
@wez wez removed the cant-reproduce The issue cannot be reproduced as described label Feb 7, 2024
wez added a commit that referenced this issue Feb 7, 2024
There are a number of open issues that relate to getting the dpi
wrong when spawning a window. In theory it shouldn't matter because
we will immediately realize the difference and synthesize the correct
information, but evidence shows this isn't quite true.

What this commit does is:

* Override Connection::default_dpi() on macOS to return the
  effective_dpi from the active screen instead of the default
  non-retina dpi
* Adjust the Config::initial_size() method to accept an optional
  cell pixel dimension
* Add a helper function to wezterm-gui to compute the cell pixel
  dimensions given the config and the (usually default) dpi, and
  feed that through to Config::initial_size
* in the macos window impl, scale the computed geometry based on
  the ratio of the Connection::default_dpi and the default non-retina
  dpi.

This helps to avoid needing to do a fixup in the
#4966 case, and may help with
the various other macos quirky issues.

refs: #2958
refs: #3575
refs: #3900
refs: #4250
refs: #4285
refs: #4447
refs: #4851
refs: #4966
@wez wez added the fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. label Feb 7, 2024
@wez
Copy link
Owner

wez commented Feb 7, 2024

This should be resolved now in main.

It typically takes about an hour before commits are available as nightly builds for all platforms. Linux builds are the fastest to build and are often available within about 20 minutes. Windows and macOS builds take a bit longer.

Please take a few moments to try out the fix and let me know how that works out. You can find the nightly downloads for your system in the wezterm installation docs.

If you prefer to use packages provided by your distribution or package manager of choice and don't want to replace that with a nightly download, keep in mind that you can download portable packages (eg: a .dmg file on macOS, a .zip file on Windows and an .AppImage file on Linux) that can be run without permanently installing or replacing an existing package, and can then simply be deleted once you no longer need them.

If you are eager and can build from source then you may be able to try this out more quickly.

@daviehh
Copy link
Author

daviehh commented Feb 7, 2024

Thanks for your hard work! Looks fixed in WezTerm-macos-20240206-225705-4f123a46

@daviehh daviehh closed this as completed Feb 7, 2024
wez added a commit that referenced this issue Feb 8, 2024
Copy link
Contributor

github-actions bot commented Mar 9, 2024

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Something isn't working fixed-in-nightly This is (or is assumed to be) fixed in the nightly builds. macOS Issue applies to Apple macOS
Projects
None yet
Development

No branches or pull requests

2 participants