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

SimpleFullscreen on macOS does not get risized when moving window across screens #1118

Closed
chrisduerr opened this issue Aug 24, 2019 · 5 comments
Labels
C - needs investigation Issue must be confirmed and researched D - easy Likely easier than most tasks here DS - macos H - good first issue Ideal for new contributors

Comments

@chrisduerr
Copy link
Contributor

This was reported to Alacritty in alacritty/alacritty#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.

@Osspial
Copy link
Contributor

Osspial commented Aug 26, 2019

cc @aleksijuvani

@ghost
Copy link

ghost commented Aug 27, 2019

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.

@ghost
Copy link

ghost commented Aug 27, 2019

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.

@mirosval
Copy link

@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.

@juanibiapina
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C - needs investigation Issue must be confirmed and researched D - easy Likely easier than most tasks here DS - macos H - good first issue Ideal for new contributors
Development

No branches or pull requests

5 participants