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

macOS: initial maximized-by-default window height (via clamping) is bigger than screen size #2918

Open
fooness opened this issue Dec 10, 2024 · 2 comments
Labels
gui GUI or app issue regardless of platform (i.e. Swift, GTK) needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer. os/macos

Comments

@fooness
Copy link

fooness commented Dec 10, 2024

Hello. First day in the beta, first maybe-issue I experienced so far.

I’m on macOS Sequoia 15.1.1, running Ghostty 0.1.0-main+5dcca190.

When starting Ghostty, the bigger-than-screen-size configured window — via the values window-height and window-width — is seemingly being clamped to the correct available screen width, but the window height is a little bit bigger than the screen height. The issue is reproducible on my Macbook-internal screen, as well as on an external monitor.

The attached screenshot shows that the tmux statusbar is basically lower than the bottom screen boundary.

#macos-non-native-fullscreen = false

window-decoration = false

window-height = 80 # also tried 1000 and other numbers
window-width = 320 # also tried 1000 and other numbers

window-padding-x = 8 # issue is reproducible with 2 (default) and 0
window-padding-y = 6 # issue is reproducible with 2 (default) and 0
window-padding-balance = false
window-padding-color = extend

Please let me know what other information I could provide, or what other things I could try.

I searched for and read through other issues, some linked below:

PS: At least one other person on Discord was not able to reproduce the problem.

Image

@mitchellh mitchellh added needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer. os/macos gui GUI or app issue regardless of platform (i.e. Swift, GTK) and removed needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer. labels Dec 10, 2024
@fooness
Copy link
Author

fooness commented Dec 11, 2024

Slight digression: I might have found a workaround or alternative solution to achieving what I thought to be the same end result; turns out this approach only achieves the end result of an initial maximized-by-default window as long as e.g. connecting, disconnecting, or switching displays, as then the window is no longer fullscreen, and the window decorations appears and rounded corners are rendered.

-  #macos-non-native-fullscreen = false          # note: was commented
+  macos-non-native-fullscreen = visible-menu    # note: is un-commented

-  window-decoration = false     # note: was un-commented
+  #window-decoration = false    # note: is commented

-  window-height = 80     # note: was un-commented
+  #window-height = 80    # note: is commented
-  window-width = 320     # note: was un-commented
+  #window-width = 320    # note: is commented

window-padding-x = 8 # issue is reproducible with 2 (default) and 0
window-padding-y = 6 # issue is reproducible with 2 (default) and 0
window-padding-balance = false
window-padding-color = extend

This workaround approach does not really work for me and my specific needs, but — assuming the described behavior is intended, i.e. don’t remember fullscreen state if displays change, I don’t see any “wrong” behavior or bugs with this approach/configuration/setup.

@the-main-thing
Copy link

I am having this issue when window-decoration = false
Removing this setting and using macos-titlebar-style = hidden works, but obviously this is not the same experience =)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
gui GUI or app issue regardless of platform (i.e. Swift, GTK) needs-confirmation A reproduction has been reported, but the bug hasn't been confirmed or reproduced by a maintainer. os/macos
Projects
None yet
Development

No branches or pull requests

3 participants