tilingWindowManager: Semi-maximize windows when possible

[3v1n0]

When a window is meant to use the whole workarea height or the whole width we can assume that the user wants to semi-maximize the window, so let's communicate this to mutter so that it will apply to the window the proper style, avoiding the window to have shadows or wrongly decorated edges

[Leleat]

Looks good generally but there are 2 (minor) issues:

This currently breaks the Restore Window Size on Grab End setting. The window will stay maximized during the grab (because of the maximize) and even a single quick click on the top panel will untile windows. These might not be worth fixing though.

I've added that setting a long time ago as a workaround for Wayland because some windows didn't restore their size properly at the beginning of a grab. Not sure, if (m)any people even used the setting in the first place, since it's hidden by default. I also don't know, if the original issue still exists. From quick testing I can't seem to find a window that doesn't restore their size on a grab start... so the setting may not even be needed anymore. And finally, I plan to rewrite the extension completely [¹]. Currently, a lot of functionality is scattered, calculated in isolation, and making it hard to add certain features/changes. So I want to rethink the organization/architecture of the code. So this issue might not be worth fixing since the code may change...

[¹] I plan to ship the rewrite with GNOME 45 (beta), so I don't break the experience for too many people, if there are regressions (only for those who are running bleeding edge, who may be used to it...😅) . If you want to, we could discuss the new extension architecture together.

Calling maximize breaks/overwrites the animations. It's not that noticable, if you tile a window by dragging it to the edges. But it's feels very bad when you use keyboard shortcuts. Currently, the window would transition from its current position to the tile fairly smoothly. With the PR, the window just immediately 'teleports' to the final position.

I am not sure what a good fix would be. Delaying the maximize call would probably be too hacky and might require fringe case handling? Maybe adding a flag to opt-in into the partial maximization would be the best. What do you think?

[Leleat]

Found one more issue. This one is pretty bad.

STR (not 100% but happens fairly often)

1. x11 only
2. Tile a window and choose another window to fill the rest with the Tiling Popup
3. Second window will appear 'corrupted until an update'.

Screencast.from.2023-03-09.23-41-35.webm

Maybe GTK4/libadwaita-related. I can't reproduce it with VSCode. Is it something we can even workaround?

[Leleat]

Found one more issue. This one is pretty bad.

STR (not 100% but happens fairly often)

x11 only
...

That bug seems to be created by a combination of Window.activate, Window.move_resize_frame, and Window.maximize.

Removing window.activate(global.get_current_time()); from the Tiling Popup at L306 seems to make issue appear less frequent... although I can still reproduce it, if I tile a window+Tiling Popup another window for a few times. So that's not really a solution.

I've opened https://gitlab.gnome.org/GNOME/mutter/-/issues/2687. Maybe someone can provide a proper fix upstream and we should disable the maximization on x11 for now?

[Edit]

and we should disable the maximization on x11 for now?

Besides making it opt-in since it breaks the animations.