Winit: SimpleFullscreen on macOS does not get risized when moving window across screens

Created on 24 Aug 2019  路  5Comments  路  Source: rust-windowing/winit

This was reported to Alacritty in https://github.com/jwilm/alacritty/issues/2741.

It seems like the simple fullscreen mode on macOS always keeps the window at the same size, even after it is moved between screens.

The expectation here is that when moving the window, it should take all of the space available on the new monitor, instead of sticking to the old size.

Toggling simple fullscreen after the window has been moved fixes this issue.

easy good first issue macOS needs investigation

Most helpful comment

@aleksijuvani Hi, I'm the original reporter from the Alacritty bug. I prefer this mode with Alacritty, as opposed to the Native Fullscreen, because its faster and more convenient to use.

  1. Native fullscreen is like a separate desktop, it is a little slower to switch to it, even if you have animations disabled. Simple fullscreen is instant
  2. I use Hammerspoon window management so that I can quickly resize the terminal to half the screen if I need to copy something from the browser for example
  3. When I open iMessage or Slack, it opens on top of the terminal, instead of switching the desktop entirely.

I used the same setup with iTerm2, where I would additionally use the cmd+u transparency toggling on occasion to copy something from the browser underneath without switching apps. None of this is possible when you use the native fullscreen.

All 5 comments

cc @aleksijuvani

It looks like the window bounds are only set upon the initial set_simple_fullscreen call. If the window is in simple fullscreen mode, we should respond to windowDidChangeScreen and change the window bounds to fit the new screen. It seems weird to me for the user to have to "move" the window to put it on another screen, however. We should change set_simple_fullscreen to take an Option<MonitorHandle> instead of a boolean. Additionally, we should track screen resolution changes with didChangeScreenParametersNotification.

That said, I would strongly prefer applications to not use the simple fullscreen functionality. The simple fullscreen mode prevents the user from using some gestures common to fullscreen applications (i.e. three-finger swipe left or right to go back to the desktop). This is because it is not in fact a fullscreen window, but a regular window with its decorations hidden. It's generally just not what users are expecting from a fullscreen application. I would love to hear about the use-cases for it, because I'm confused as to why anyone would want this behaviour.

@aleksijuvani Hi, I'm the original reporter from the Alacritty bug. I prefer this mode with Alacritty, as opposed to the Native Fullscreen, because its faster and more convenient to use.

  1. Native fullscreen is like a separate desktop, it is a little slower to switch to it, even if you have animations disabled. Simple fullscreen is instant
  2. I use Hammerspoon window management so that I can quickly resize the terminal to half the screen if I need to copy something from the browser for example
  3. When I open iMessage or Slack, it opens on top of the terminal, instead of switching the desktop entirely.

I used the same setup with iTerm2, where I would additionally use the cmd+u transparency toggling on occasion to copy something from the browser underneath without switching apps. None of this is possible when you use the native fullscreen.

I never use native full screens. There is no shortcut for them, unlike with spaces where you can have ctrl+1 etc. This is my use case, and it's not just alacritty, it's every app.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JDTX picture JDTX  路  3Comments

alexheretic picture alexheretic  路  4Comments

felixrabe picture felixrabe  路  3Comments

tomaka picture tomaka  路  3Comments

ryanisaacg picture ryanisaacg  路  3Comments