Weird maximize animation in multimonitor setups (Related to #188)

[dolwup]

Describe the bug After the fix for #188 was added windows are maximized to the right monitor but the maximize animation looks off. It seems like the starting point for the animation are the coordinates of the window of the top monitor but mapped to the lower one.

Steps To Reproduce

1. Grab a window (super + drag makes this a bit
2. Move it so its moslty on another
3. Touch the top edge and
4. Window tiles to the other monitor instead the one where the top edge was touched

System Info:

• Distro (incl. version): Arch Linux
• GNOME (Shell) version: 42.3.1
• Extension version and from where (e. g. EGO, main branch...): main
• XOrg/Wayland: Wayland

Journalctl logs None

Screencasts

https://user-images.githubusercontent.com/38048361/179583491-0bed19ab-9325-444d-874d-1aa78fc4ee4d.mp4

[Leleat]

After the fix for https://github.com/Leleat/Tiling-Assistant/issues/188 was added windows are maximized to the right monitor but the maximize animation looks off.

The issue in #188 came to be because the grabbed window is maximized using a 'true maximize' (i.e. GNOME's native maximizing function). So if you grabbed the window on the lower half and moved it to the top edge, where there is another monitor, the window will technially be considered to be on the top monitor. And thus maximize on that monitor. The fix to this was to move the window to the monitor where the pointer is before maximizing it. So there are sort of multiple movements happening and it 'breaks' the animation.

I don't think I can really 'fix' it. I didn't write any animation into my extension. I just (mis-)use GNOME's native animations for my own extension.

If you used T-A prior to v34, you may wonder why that didn't happen before... Before v34 issue #188 didn't happen because I didn't use a true (aka GNOME's) maximize. I used my own tiling function to tile the window to fill the entire monitor. Technically, this was a bug and fixed for v34, which led to #188. I prefer to use a true maximize because my tiling function basically just moves and resizes windows like a user... just programmatically. This means some apps like GNOME Terminal will have gaps if they are tiled/maximized with my tiling function.

So the question is what's more acceptable? A bad animation or gaps on some windows? (Or should a 'true maximize' be an opt-in setting?)

[dolwup]

I actually never had any issues regarding gaps around some maximized windows. Every window was properly maximized (no gaps around the infamous gnome-terminal, straight corners instead of rounded like windows were properly maximized etc.)

[Leleat]

I actually never had any issues regarding gaps around some maximized windows. Every window was properly maximized (no gaps around the infamous gnome-terminal, straight corners instead of rounded like windows were properly maximized etc.)

The gaps around a 'maximized' GNOME Terminal should only appear on v33 if you tried to maximize it like you describe it above (i. e. the window being mostly on a different monitor). You should have gaps around a 'tiled' GNOME Terminal though, right?

[dolwup]

Yes I can confirm that. Gnome does that fine though on its own (maximizing to the right monitor with the correct animation) idk if it would be better to only handle maximize if gaps around maximized windows are enabled? This would propably break the grace period though. I don't really know the inner workings of TA and how gnome-shell extensions work (limitations and such) so these are just random thoughts based on assumptions :sweat_smile:

[Leleat]

dec9e72ee87973f08ebcf787c77e94d413aefc65 changed the behaviour so that a true maximize is only used, if the setting gaps for Maximized Windows is disabled. In all other cases T-A just 'tiles' the window to fill the entire workspace. That means with that setting you can either choose a bad animation under the circumanstances mentioned in the original comment or accept gaps on some maximized windows and have slightly better animations. Beyond that I don't think there isn't anything I can do...

[dolwup]

Maybe you could, in the case described above, instead of moving the window down first and maximizing it afterwards tile-maximize it onto the (in this case) lower monitor and maximize it after the animation. This would be weird in another way but I think it would not less noticable

[Leleat]

Maybe you could, in the case described above, instead of moving the window down first and maximizing it afterwards tile-maximize it onto the (in this case) lower monitor and maximize it after the animation.

This means I have to introduce a noticable delay before using the true maximize. This would probably introduce a few other issues like when someone tries to maximize and unmaximize quickly. I don't think that's really worth it. It would probably also look weird on GNOME terminal and other apps with gaps since you would first use a maximize animation, where it has gaps, and then the true-maximize animation, where the gaps disappear.