Imperfect/Inconsistent (?) resizing in regards to window snapping and maximizing

[xenanthropy]

This has been an issue for as long as i've used berry but finally decided to make an official issue.
I've noticed that when moving windows with keybinds (either mod + O/P to snap left or right, or mod + M to maximize) it doesn't perfectly resize/place the window on first key-press; You have to press the same keybind again and it will shift the window size/position to properly lock it into whatever configuration you just pressed (it's usually a matter of just a few pixels).

I've attached screenshots to show what I mean. I'm not sure if this is a math issue in code when resizing windows or what, but it is a bit frustrating if you notice it (I happen to be demonstrating this issue in sourcemage linux, but it happens on every system that i've tried berry on, both real hardware and virtual machines, and over multiple berry versions)

(it can be hard to notice the differences, but for maximize, there's a few pixels of deadspace to the right on the first mod-m. Pressing Mod-m a 2nd time correctly fills the rest of the space with the terminal window. Same with Mod-O, the first press doesn't correctly fill up the entire left half of the screen - a second Mod-O extends the window to the right by a few pixels to correctly fill exactly half the screen with the window)

(For more information, the resolution of this current setup is 1366x768, but i've had this happen at any resolution on other machines)

[xenanthropy]

To rule out some things - I've also replicated this issue without the window title borders, so that's not something that's affecting this

[xenanthropy]

Even extra information! (Sorry, really don't want to add all of this into the main post, it's already a mess to read) A while back, I made some modifications to berry in order to add the functionality of quartering windows, in order to snap to topleft, topright, bottomleft, bottomright (Didn't officially fork it so my changes were undocumented, i'm sorry open-source community) . The code I hacked together was the same code used for Mod-O/P, but just halved. In my testing, quartering windows worked BUT I ran into this same issue of having to use two key presses in order to fully lock the window to the correct dimensions. With the current Mod-O/P and Mod-M issue, it's an issue on the horizontal axis (the windows are the correct vertical height on first keypress) with my modification, both horizontal height and vertical height were wrong, so it would shrink/expand in both directions, depending on whether the window was topright, bottomleft, etc. etc.
This lends further credence to it being an issue either with the math used to move the windows, or the function of moving the windows itself.

[JLErvin]

Thanks for the detailed write-up. Whats the terminal application you're using?

[xenanthropy]

Thanks for the detailed write-up. Whats the terminal application you're using?

xfce4-terminal in this instance, although this happens with any application (i'm just displaying the issue with this because my current system is very bare, I don't have any other screenshot applications installed beside scrot) I could spin up a VM (maybe archcraft, they have a berry config) and screenshot the same issues if need be! I didn't pick a very good system to display this problem on

[JLErvin]

Hmmmm, I'm not able to repro this. Can you post your autostart?

[xenanthropy]

Hmmmm, I'm not able to repro this. Can you post your autostart?

Yeah sure! My autostart is just the default one that comes with berry, with my sxhkd start line (sxhkd -c ~/.config/berry/sxhkdrc) at the top of it.

Interestingly enough, i'm testing it with other windows and it actually doesn't seem to be having the same issue... I swear I remember it happening with all programs (although admittedly it's been awhile since i've daily driven berry, I could be mistaken) It is however consistently happening with my terminal window (which is xfce4-terminal)

I'm going to load up a vm and do some testing, see if I can get this bug to happen with other programs, or see if it's possibly a bug with only terminals/only xfce4-terminal

[xenanthropy]

Ok, update! I'm actually on my main system now, I already had berry installed so I logged out and switched to it (i'm on Arch)
I cannot produce the bug with any other programs except terminals! I've tried multiple terminals now, here are my findings:

Alacritty: fine
Sakura: fine
xfce4-terminal: bug
gnome-terminal: bug
urxvt: fine
uxterm: fine
xterm: fine
kitty: fine

I can only seem to reproduce the bug with gnome-terminal and xfce4-terminal (this is on both of my systems, so not distro-specific) I would say it's a VTE issue (as xfce4 and gnome terminals are both VTE-based) but Sakura is also VTE-based and doesn't have the issue, so i'm stumped.

If you can, try out both xfce4-terminal and gnome-terminal in your testing and see if you can reproduce.

Edit: I found an easy way to notice the bug is by doing Mod-O, Mod-M, Mod-M. With a regular window, it will snap to the left, maximize, then the 2nd Mod-M will snap it back to the left again (unminimizing, taking it back to it's original position) with the bugged terminals, the 2nd Mod-M will properly maximize the window. However, upon a 3rd Mod-M and consequent presses, it just alternates between 'barely not maximized' and 'maximized' it does not properly go back to it's previous Mod-O position.