Add config option to always open window in full screen/maximized

[JoyceBabu]

Is your feature request related to a problem? Please describe.
When using wezterm on laptop, the window size is too small and I have to maximize the window everytime.

Describe the solution you'd like
It would be really nice, if it there is a configuration option to always open the window in full screen/maximized.

Describe alternatives you've considered
Similar behaviour can be obtained by setting initial_rows and initial_cols, but needs to be configured per machine/monitor.

Additional context

#256 #177

[FLX-0x00]

This would be nice. Just replaced my terminal with wezterm and this is the only thing i missed at this time.

[AlectronikForge]

These params initial_rows and initial_cols should be better visible in the config part of the website, at least I was just up to open a wish report for them when I stumbled upon this here and finally was able to have WezTerm open at a favourable size..

[gwww]

While a config option might be OK for some situations, I want window:perform_action("Maximize") then in something such as #674 I could then have logic for what deciding what to do. For example in the event code I could look at the DPI of the screen (as a hack to know which screen I'm on) and only maximize if I'm on my laptop screen. I could also in the event handler do things such at SplitHorizontal, etc.

[lucatrv]

Just as a note, I can start Wezterm maximized by simply setting initial_cols and initial_rows to any values above the maximum ones possible on my screen (for instance initial_cols = 200 and initial_rows = 50).

@wez, maybe this behavior should be documented? I can send a PR if you wish.

[wez]

This issue serves as documentation for workaround(s) for now: I'd rather have a PR that focused on making the requested feature work :)

[chtenb]

Just as a note, I can start Wezterm maximized by simply setting initial_cols and initial_rows to any values above the maximum ones possible on my screen

That doesn't work for me on windows. The window will actually take those dimensions.

[agkitspersonal]

It actually extends to my second monitor. It's better for me to not set any values there.

[wez]

Current main allows you to add this to your config to maximize the initial window:

local wezterm = require 'wezterm'
local mux = wezterm.mux

wezterm.on("gui-startup", function()
  local tab, pane, window = mux.spawn_window{}
  window:gui_window():maximize()
end)

return {}

Windows and Wayland nightly builds with this feature are currently building, but X11 and macOS builds already have it available.

[chtenb]

It doesn't seem to work on windows. It does start in the topleft corner now, but not maximized. It has the same size as before.
It does think it's maximized though, because windows-up doesn't do anything. Only when I press windows-down windows-up it gets maximized.

[wez]

@chtenb: should be fixed now in main!

[gwww]

I just tested and it works as expected. I removed my lines/cols "hack" settings to try and the result was correct. Thank-you!

[chtenb]

Yes it works now @wez !

[jackos]

Works great on Mac thanks @wez, but for anyone that this isn't working for, having this setting will not allow it to work:

return {
    window_decorations = "NONE"
}

To get rid of the title bar and still allow this to work you can do:

return {
    window_decorations = "RESIZE"
}

[JoyceBabu]

Thank you. It is working great.   🎉

Is it possible to disable the resize animation when calling the maximize method?

[wez]

Is it possible to disable the resize animation when calling the maximize method?

assuming you mean macOS: as far as I can tell, no, there isn't a way for an application to use the standard NSWIndow::zoom method without it animating.

Instead of window:maximize() you may wish to use window:toggle_fullscreen() which, by default (unless you have changed native_macos_fullscreen_mode) will go fullscreen without the annoying animation.

[JoyceBabu]

Instead of window:maximize() you may wish to use window:toggle_fullscreen() which, by default (unless you have changed native_macos_fullscreen_mode) will go fullscreen without the annoying animation.

That worked perfectly. Thanks.

toggle_fullscreen hides the menu bar too on macOS. So I am going with maximize itself. Thank you for adding the maximize support.

[tgharib]

Current main allows you to add this to your config to maximize the initial window:

local wezterm = require 'wezterm'
local mux = wezterm.mux

wezterm.on("gui-startup", function()
  local tab, pane, window = mux.spawn_window{}
  window:gui_window():maximize()
end)

return {}

Windows and Wayland nightly builds with this feature are currently building, but X11 and macOS builds already have it available.

This worked wonderfully on Windows but I seemed to have lost the ability to use wezterm-gui start. For example: wezterm-gui start -- nvim now takes me to a fresh prompt instead of launching neovim. Here is my full config on Windows if it's relevant. I have commented out the maximize code for now since launching nvim is important to me.

[wez]

@tgharib ah, good catch. Yeah, that's a pain. I've pushed a commit that now encodes the wezterm start program arguments into a SpawnCommand object, so you can do:

local wezterm = require 'wezterm'
local mux = wezterm.mux

wezterm.on("gui-startup", function(cmd)
  local tab, pane, window = mux.spawn_window(cmd or {})
  window:gui_window():maximize()
end)

return {}

[wez]

That should show up in a nightly build for windows within about an hour from now.

[14Si]

I don't think the solutions above apply to windows spawned by wezterm ssh <>@<>

[wez]

@14Si: 8b2ef50 makes gui-startup work for wezterm ssh

[stevenxxiu]

Thanks for this feature. I tested your code @wez, but the terminal always flickers on startup. It starts out as a small window, as configured (or not) via initial_rows and initial_cols, then maximizes.

Is there a way to avoid this flickering?

[jfaz1]

@wez @stevenxxiu have the same issue, but also messes up Open WezTerm Here in Windows. Shell ends up defaulting to the user directory instead of the folder in which it was invoked.
Looks like:

wezterm.on("gui-startup", function()
  local tab, pane, window = mux.spawn_window{}
  window:gui_window():maximize()
end)

[wez]

@jfaz1 check out the docs at https://wezfurlong.org/wezterm/config/lua/gui-events/gui-startup.html and you'll see that the cmd object passed to the event can be used to pass through other information from wezterm start:

local wezterm = require 'wezterm'
local mux = wezterm.mux

wezterm.on('gui-startup', function(cmd)
  local tab, pane, window = mux.spawn_window(cmd or {})
  window:gui_window():maximize()
end)

return {}

[jfaz1]

@wez Thanks for the reply! I tried that snippet earlier and it didn't work, but I moved up in the config and for some reason it worked this time. It's almost there, only thing missing besides what @stevenxxiu brought up is that the left side starts cut-off:

It's meant to read PS . If I un-maximize it and maximize it again it looks normal:

[wez]

Please open a separate issue for that!

[trymoto]

If you're on MacOS and want wezterm to natively maximize the window you can:

local wezterm = require 'wezterm'
local mux = wezterm.mux

wezterm.on("gui-startup", function()
  local tab, pane, window = mux.spawn_window(cmd or {})
  window:gui_window():toggle_fullscreen()
end)

return {
  native_macos_fullscreen_mode = true,
}

Also, animation to fullscreen might mess up sizes if you're immediately spawning stuff.
It's best to also call wezterm.sleep_ms(1) after that

[rbutoi]

I can't tell why this was closed? AFAICT there's still no config option to do this -- enabling fullscreen interactively at runtime or with some kind of sleep seems hacky. I'd like to use wezterm for one-off fullscreen terminal dialogs that I currently still use kitty --start-as=fullscreen for.

[wez]

It's closed because this issue asked for a configuration option and there is a more powerful configuration option for this documented in:

• https://wezfurlong.org/wezterm/config/lua/gui-events/gui-startup.html
• https://wezfurlong.org/wezterm/config/lua/gui-events/gui-attached.html (new in nightly builds)

a command line flag is a different thing; please file a separate issue for that if that is something you'd like to have considered as a future enhancement.

I'm going to lock this issue because tracking and responding effectively to comments on a closed issue is difficult.