Which dimensions should resize increments be relative to?

[madsmtm]

Should they be relative to the window's dimensions, or the surface?

On macOS it's currently the surface, as that's what was decided in #2411 (comment), but perhaps that's wrong? @kchibisov why is this incorrect, when would you ever want your resize increments to be relative to the window's frame, i.e. including decorations?

Spun off from #3889.

[madsmtm]

As I understand it, the use-case for resize increments is terminal emulators, who want to make their terminal snap nicely to the size of a character. If that's the case, the resize increments should definitely be relative to the surface, otherwise you would still end up snapping halfway inside a character? Or is there something I'm not understanding here?

[kchibisov]

On macOS it's currently the surface, as that's what was decided in #2411 (comment), but perhaps that's wrong? @kchibisov why is this incorrect, when would you ever want your resize increments to be relative to the window's frame, i.e. including decoration

They generally apply for the whole thing, so increment for the whole window applies the same for the inner surfaces? However there's a case when only some surface will be resized.

Especially given that the decorations are fixed sized and don't grow if you grow the window.

It's a matter of a platform really, but on Wayland it's for window and all other methods are for window.

Surface has no events on Wayland other than scaling/rotation, and the only target for sizing suggestions is window.

[madsmtm]

the only target for sizing suggestions is window.

That seems like it'll only be useful in non-decorated windows, then? Or is there some way to make it work properly for decorated windows? If not, perhaps we should document that too?

[madsmtm]

Wait... Resize increments aren't even implemented on the Wayland backend?

[kchibisov]

You implement resize increments on Wayland by tracking the live resize and _adjusting the window size the way you want.

They are useful regardless, since you set the step, and step will work correctly even if you have decorations around the window. And there's a way to account for decorations around the window anyway...

Maybe for surface it's fine, it's just when you have e.g. 3 surfaces inside one window, it's not clear how you'd use this API if it's not on window.

[madsmtm]

when you have e.g. 3 surfaces inside one window, it's not clear how you'd use this API if it's not on window.

True, if/when we consider sub surfaces, this will clearly only apply to a single surface - and on macOS, it can only apply to the root surface. But I'd punt on that for now.