wezterm icon indicating copy to clipboard operation
wezterm copied to clipboard

fullscreen & maximize mode leaves some empty space

Open fzhnf opened this issue 1 year ago • 3 comments

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

Linux Wayland

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

kwin 6.2.0, KDE Plasma 6.2.0

WezTerm version

wezterm 20241007_103714_ed430415

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

i can resize the window to fill the screen, and i do that every time because the max/fullscreen mode has an empty space below, i thought it is because of kde panel on the left screen , but it still show the same result when i put the panel on top, i tried no config with flag "-n", the space is still there,

maximize: image

fullsceen: image

To Reproduce

  1. open wezterm on kde 6.2.0
  2. try maximize & fullscreeen

Configuration

no config

Expected Behavior

wezterm full/maximize mode take the empty space

Logs

17:33:45.638 INFO wezterm_gui > Spawned your command via the existing GUI instance. Use wezterm start --always-new-process if you do not want this behavior. Result=SpawnResponse { tab_id: 3, pane_id: 3, window_id: 3, size: TerminalSize { rows: 24, cols: 80, pixel_width: 640, pixel_height: 384, dpi: 0 } }

Anything else?

No response

fzhnf avatar Oct 09 '24 09:10 fzhnf

Same issue. Did a bisect and found the first bad commit to be c75d300f6f2589a6a8d8f4cc537f5e8a1be55de7.

@aliaksandr-trush, you seem to be the author of that change. Could you please take a look?

# bad: [ed430415ee69279ea692358525196ad7d4c965b8] add X11 xmonad to tiling_desktop_environments
# good: [1c4fdd3f7131785d0afaed08bed6cf1856f84328] ci: refine triggers for no-response workflow
git bisect start 'main' '1c4fdd3f'
# bad: [de0ecc60eb5073015c4ccfe301e7895bb7bdf8ee] docs: changelog for #6054
git bisect bad de0ecc60eb5073015c4ccfe301e7895bb7bdf8ee
# bad: [d7938cb6b2f5dd9214dea4e1e491d5b8f917dc1f] wayland: handle left/right tiling too
git bisect bad d7938cb6b2f5dd9214dea4e1e491d5b8f917dc1f
# bad: [c75d300f6f2589a6a8d8f4cc537f5e8a1be55de7] feat: implement toggle_fullscreen and hide for Wayland
git bisect bad c75d300f6f2589a6a8d8f4cc537f5e8a1be55de7
# good: [16a8bcdd89653205b446628a3107c8292ae2ba0d] fix(wayland): match inner window and window frame sizes
git bisect good 16a8bcdd89653205b446628a3107c8292ae2ba0d
# first bad commit: [c75d300f6f2589a6a8d8f4cc537f5e8a1be55de7] feat: implement toggle_fullscreen and hide for Wayland

hexchain avatar Oct 10 '24 09:10 hexchain

There is some issue with Wayland configure event that I am still investigating. Created issue for it: https://github.com/wez/wezterm/issues/6262

aliaksandr-trush avatar Oct 10 '24 10:10 aliaksandr-trush

I'm not sure if this belongs over in #6262 , but I think the issue (for me) is that my display is set to 125% scaling

When I reconfigure my compositor to use 100% scaling, the "inner window" much more closely fits the "outer window"

But for 125% or 200% scaling, the inner window only seems to fill the top-left quarter of the outer window

It's less obvious when you have tiling or maximised the window, but very obvious when the window is floating (but I think the problem is still present when tiled/maximised)

jokeyrhyme avatar Oct 16 '24 07:10 jokeyrhyme

@jokeyrhyme yes it's, I have the issue when the window is maximised.

LuisanaMTDev avatar Nov 28 '24 01:11 LuisanaMTDev

I have the same issue on Fedora 41 with Wayland and KDE 6.2.4.

As a temporary fix, the flatpak version is not affected (guessing it uses wayland-x11) :(

nmilosev avatar Dec 28 '24 18:12 nmilosev

Looks like issue with refresh_frame() call. Could you verify how https://github.com/wez/wezterm/pull/6545 works for you?

aliaksandr-trush avatar Jan 03 '25 12:01 aliaksandr-trush

I no longer see any gaps with #6545 applied, under Plasma 6.2.5.

hexchain avatar Jan 03 '25 13:01 hexchain

Hmmm, I'm not sure, @fzhnf , but it doesn't look like #6545 has been merged yet

But ... I also don't know if the expectation is for issues to remain open until fixes have been merged ... :shrug:

jokeyrhyme avatar Jan 04 '25 08:01 jokeyrhyme

on windows and i'm getting this issue with a thin border around every side image notice the orange lines and top and left and white strips at the bottom

edit:

nevermind, my issue was because of overrides.window_decorations = 'INTEGRATED_BUTTONS|TITLE' causing some empty space.. i did some research and it seems to be a common issue. to get around this i made a callback for window-resized events:

function fullscreen_toggle(window, pane)
    local overrides = window:get_config_overrides() or {}
    local is_fullscreen = window:get_dimensions().is_full_screen
    
    if is_fullscreen then
        overrides.enable_tab_bar = false
        overrides.window_decorations = 'NONE'
	wezterm.log_info("Setting to fullscreen mode")
    else
        overrides.enable_tab_bar = true
        overrides.window_decorations = 'INTEGRATED_BUTTONS|TITLE'
    end
    
    window:set_config_overrides(overrides)
end

wezterm.on('window-resized', fullscreen_toggle)

current issue

the above solution works well for me except for when i fullscreen for the first time. for some odd reason, the first full screen successfully triggers the event as it should, but the transparent border persists. but when i exit full screen and then go back into it again, its gone (and stays that way for any subsequent full screen toggling). not sure why this is happening, will update if i figure this out.

mrdandelion6 avatar Jan 12 '25 06:01 mrdandelion6

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[bot] avatar Feb 12 '25 03:02 github-actions[bot]