Implement gaps to maximized windows on double-click

[CharlieQLe]

This should add gaps to windows that are maximized via double-click. This applies only to windows that are designated as normal, but I'm unsure if that is necessary.

[Leleat]

Looks like it is possible to freeze the system. If you disable the toggle to add gaps to Maximized Windows or if the screen gaps are 0, tile() will use a 'true maximize' (i. e. mutter's maximize() function), which fires a size-change signal, which then calls tile() again causing an endless loop.

[Edit]

There is also an extra empty line in line 1226.

[Leleat]

I think you also need to cover the case to 'unmaximize' a window, if it's already fake-maximized.

[CharlieQLe]

Added a check that would only maximize with gaps if at least one of the screen edges has a gap value greater than 0 and if the setting is enabled, which should stop any loops. Windows with gaps that are maximized via double click should also be untiled now, but I ran into a few bugs.

The window size isn't restored to the proper size, but it is smaller than the maximized window now.

If a window was maximized by being dragged to the top, then resized, then trying to maximize by double clicking will "untile" the window, but double clicking again maximizes the window properly.

Firefox also gets stuck in the maximized state, but it can be resized as if it were floating. Firefox can go back to the unmaximized state, but I have no clue if this is just a Firefox bug. I assume it is a bug with this implementation of gaps for windows maximized via double click, since it only happens with that.

[Leleat]

If a window was maximized by being dragged to the top, then resized, then trying to maximize by double clicking will "untile" the window, but double clicking again maximizes the window properly.

This is a pre-existing bug (although it's not obvious since currently you can only add gaps to maximized windows via dragging to/from the top bar). The issue is that maximized windows with gaps have a tiledRect property but don't have that tiledRect be adjusted after a resize in the resizeHandler. So the tiledRect will still equal the work area after a resize. This is easily fixable.

The window size isn't restored to the proper size, but it is smaller than the maximized window now.

Issue seems that untile is called twice and causing some problems. The flow looks like this

1. double-clicking on a window, which is maximized with gaps, will first call a true maximize (with Meta.MaximizeFlags)
2. this calls _onWindowSizeChange, which calls the first untile()
3. in untile() you will call Meta's unmaximize, which causes the second _onWindowSizeChange and untile

Should be fixable(?)...

Firefox also gets stuck in the maximized state, but it can be resized as if it were floating. Firefox can go back to the unmaximized state, but I have no clue if this is just a Firefox bug. I assume it is a bug with this implementation of gaps for windows maximized via double click, since it only happens with that.

I also couldn't properly maximize Nautilus. Nautilus got stuck in some inbetween state. Don't think there is much we can do here. So trying to tile a window after a size-change signal doesn't seem to be the way to go since it doesn't work for all apps. Do you have any alternative plans?

[CharlieQLe]

The first two issues should be fixed now. The last one seems to be more application dependent though? Nautilus seems to invoke _onWindowSizeChange twice (it maximizes, unmaximizes, maximizes, and unmaximizes, thus maintaining its position and dimensions) instead of once (maximizing then unmaximizing). With Firefox, I have to double click multiple times in order for the window to maximize and it still keeps sharp corners instead of rounding them.

EDIT: Calendar 42.1 seems to have bugged corners with this, but is otherwise completely fine. Text Editor 42.1 seems to be fine, so I don't think it is a GTK bug. Could just be Wayland, I'll have to check the X11 session to see if it is a problem there too.

EDIT 2: The Calendar corners is indeed a Wayland bug, so I think the problem there is with Mutter. The other problems still happen in the X11 session though. I also noticed that some windows start out with Mutter's maximization, but that shouldn't be hard to fix.

[Leleat]

That's quite problemtic IMO. This feature seems very hit or miss. People probably wouldn't want that. After all, those apps are popular/frequently used. So those issues would be very noticable.

If you really want to see this PR merged, I'd like this feature hidden behind an advanced setting, disabled by default, with a warning that it's buggy (in the subtitle of the settings row).