hyprwm
Foot terminal incorrect size for a brief moment on startup
Hyprland Version
main branch commit e2f18f8c7f95e4094acb94c5a06dc6d75d7fc9c1
Bug or Regression?
Bug
Description
The foot terminal briefly opens with a much smaller size.
Creator says it's not a foot issue.
https://codeberg.org/dnkl/foot/issues/1211 https://codeberg.org/dnkl/foot/issues/1133 https://github.com/swaywm/sway/issues/2176
How to reproduce
- Open foot (v1.16.2) with animations
Crash reports, logs, images, videos
we can't really "predict" the size on map the window should become reliably with the current codebase, but we could just set it to the monitor's res and adjust when it is mapped
i'm using a little workaround:
add initial-window-size-pixels=2000x2000 to foot.ini, or just ur monitor size
to avoid problems when launching with [float] exec-rule, u can add
windowrulev2 = size 1016 648,class:^(foot)$,floating:true
windowrulev2 = center 1,class:^(foot)$,floating:true
to ur hyprland.conf and use a wrapper script for togglefloating bind:
#!/usr/bin/bash
dump=$(hyprctl activewindow -j | jq -r '.initialClass+" "+(.floating|tostring)')
read -r class float <<< "$dump"
if ! $float && [[ $class == foot ]]; then
hyprctl --batch \
"dispatch togglefloating active; \
dispatch resizeactive exact 1016 648; \
dispatch centerwindow"
else
hyprctl dispatch togglefloating
fi &>/dev/null
adjust sizing at your taste
I have this same problem, but only with Foot and Alacritty.
Kitty, Wezterm and GNOME terminal do not have this problem.
https://github.com/hyprwm/Hyprland/assets/53343401/95e756e8-bbc8-44ad-b02e-c4f1d7f20981
I can't say how long ago or give an exact version of when this happened, but I'm pretty sure this didn't happen before, both in Alacritty and Foot.
yes, it would be stretched to fill instead, looking wonky and technically being non-protocol-compliant
btw problem disappeared with foot for me, although i can't tell what commit exactly had affected it, i just accidently noticed when launched foot without wrapper-script and no config
Still happening for me on Hyprland 62a8d0be5c1959ade8410f8f964e362288f22175 and foot 1.16.2 Gonna re-test with the latest commit soon
foot 1.16.2-2 @ arch hyprland-git 36fa33f7ca2f555cc8581a13c5899effed2bf84b
no foot updates since i saw those glitches, so it should be some hyprland commit
actually it is barely seen on recording, but it's due to encoding settings my recorder uses, nothing seen in real world
https://github.com/hyprwm/Hyprland/assets/130279855/2d2f5cec-a206-43bd-8076-5a129d4dd2db
default hyprland.conf and foot without foot.ini
Still happening for me on b1b8d732e64ecf527baef010ad2f28ed3b8c4ac1 (with default foot config)
guys I'd like you to please stop commenting it's happening. I do realize. You just spam my inbox.
This will not be fixed anytime soon. For foot, a workaround that works on both sway and hyprland has been posted and it's to make the initial size bigger in foot's cfg.
well, after 763d5fa windowzise-related options in foot.ini are completely ignored, which is sad, cause there is window-size-chars option to get pixel-perfect size depending on your font, which is very useful when using different fontsizes for multiple monitors with different dpi
Now it just stretches to monitor size when started with hyprctl dispatch exec "[float]foot" or just with float windowrule in config, or after togglefloat. Seems like a time to make another bunch of windowrules :rofl:
FYI https://github.com/hyprwm/Hyprland/commit/763d5fa05f7d0191182a1d6cd827415a65293f99 breaks wezterm. It says it's started but does not appear, and hyprctl clients lists only broken clients:
{
"address": "0x3950050",
"mapped": false,
"hidden": false,
"at": [
0,
0
],
"size": [
0,
0
],
"workspace": {
"id": -1,
"name": ""
},
"floating": false,
"monitor": -1,
"class": "",
"title": "",
"initialClass": "",
"initialTitle": "",
"pid": -1,
"xwayland": false,
"pinned": false,
"fullscreen": false,
"fullscreenMode": 0,
"fakeFullscreen": false,
"grouped": [],
"swallowing": "0x0",
"focusHistoryID": -1
}
what about this? https://github.com/hyprwm/Hyprland/issues/4022#issuecomment-1859595445 windowrules are only waytogo now?
oopsie, i see. and it actually not totally gone. i can see black rectangle again, but seems only when launching floating above existing window
I wonder if its possible to account for gaps and window borders? Some terminal applications (e.g. nvtop) will open with a slightly larger size on startup, causing them to flash and resize again a bit later (since the terminal just became smaller by like 3-4 columns) (prediction is bigger than the window size because of borders and gaps)
It also happens with my terminal prompt which has items on the right side. I get small visual artifacts on startup because the prompt is resizing itself again