Add decoration parameter to Window and DialogWindow to control the thickness of the undecorated window resizers.

[m-sasha]

The thickness of the undecorated window resizers is currently hardcoded to 8.dp. This PR adds a composition local, LocalUndecoratedWindowResizerBorderThickness to allow users to change it.

Fixes JetBrains/compose-multiplatform#4574

Testing

Tested manually with:

fun main() = application {
    var thickBorders by remember { mutableStateOf(false) }
    Window(
        onCloseRequest = ::exitApplication,
        decoration = when {
            thickBorders -> WindowDecoration.Undecorated(40.dp)
            else -> WindowDecoration.Undecorated()
        }
    ) {
        Row(
            verticalAlignment = Alignment.CenterVertically,
            modifier = Modifier
                .fillMaxSize()
                .padding(100.dp)
        ) {
            Checkbox(
                checked = thickBorders,
                onCheckedChange = { thickBorders = it },
            )
            Text("Thick resizers")
        }
    }
}

It's difficult to write an automated test for this because UndecoratedWindowResizer relies on MouseInfo.getPointerInfo() which can't be simulated from tests.

Release Notes

Features - Desktop

The thickness of border resizers in undecorated windows and dialogs can now be controlled by passing a new decoration argument.

[MatkovIvan]

API Guidelines:

Avoid implicit inputs provided via CompositionLocal

[m-sasha]

API Guidelines:

Avoid implicit inputs provided via CompositionLocal

We don't currently expose UndecoratedWindowResizer, so there is no place to pass an explicit argument.
We could expose it, or provide an additional parameter to Window and DialogWindow, but each of those comes with its own considerations and downsides.

[igordmn]

Suggested change

	interface WindowDecoration {
	sealed class WindowDecoration {

AOSP uses sealed class in a case when it isn't possible to have custom implementation.

[m-sasha]

I thought we didn't want to use sealed or enum classes because it can make it hard to provide backwards compatibility later when we want to add additional subtypes. For example, someone can write

when (decoration) {
    is System -> ...
    is Undecorated -> ...
}

and when we add another type, this will be broken.

[igordmn]

Right 🤔, let's keep interface

[MatkovIvan]

Agree with @igordmn - it should be sealed, but not class, sealed interface should work here. I guess it's covered by some policy - need to look for formal rule there, but the idea is to avoid implementation outside of our code. Explicit requirement in case of adding is pro, not cons

[Sanlorng]

Agree with @igordmn - it should be sealed, but not class, sealed interface should work here. I guess it's covered by some policy - need to look for formal rule there, but the idea is to avoid implementation outside of our code. Explicit requirement in case of adding is pro, not cons

If we design this interface similar to TextFieldDecoration and move the implementation of the Undecorated Resizer to this part, it can be provided to users to achieve an immersive title bar application experience on Windows. This requires exposing the Window to set window properties and exposing the HitTest related interfaces for hit testing of controls within the title bar. You can refer to this existing implementation for specifics. Additionally, in the current Resizer implementation, if the user calls a Dialog or Popup, the Resizer response will be blocked and won’t respond . If we implement the Resizer through this new interface and always place the WindowDecoration field above the ContentLayer, can this solve the problem? Would this design make the Decoration API more user-friendly and extensible?

[igordmn]

Looks good 👍. Let's wait for the second approval.

[MatkovIvan]

Agree with @igordmn - it should be sealed, but not class, sealed interface should work here. I guess it's covered by some policy - need to look for formal rule there, but the idea is to avoid implementation outside of our code. Explicit requirement in case of adding is pro, not cons

[MatkovIvan]

I'd move it from global scope to companion object

[m-sasha]

Agree with @igordmn - it should be sealed, but not class, sealed interface should work here. I guess it's covered by some policy - need to look for formal rule there, but the idea is to avoid implementation outside of our code. Explicit requirement in case of adding is pro, not cons

If we want a sealed interface here, we need to hide the actual subtypes from the user, to make the when scenario I mentioned impossible.

[igordmn]

I'd move it from global scope to companion object

We can reuse the AOSP pattern:

object WindowDecorationDefaults {
    val ResizerThickness: Dp = 8.dp
}

It is more preferable over companion object, because it will be consistent with AOSP

[igordmn]

On the other hand, it is only for Undecorated.

I delegate the decision to @m-sasha

[MatkovIvan]

we need to hide the actual subtypes from the user, to make the when scenario I mentioned impossible.

Why do we need to hide it? Why do we want to make such switch/when impossible?

[MatkovIvan]

Explicit requirement in case of adding is pro, not cons

It's OK to require extra case handling in this case. It won't break binary compatibility that we have to maintain

[m-sasha]

I'd rather not dive into the exact semantics of what binary compatibility means.

De-facto, valid code that was written and compiled before the addition of another subtype will crash at runtime afterwards. That's breaking existing code.

[MatkovIvan]

Yes, sure. But the policy for breaking source code compatibility is MUCH softer than for binary compatibility. The reason behind this is affecting 3rd party libraries that users cannot control.
It doesn't sound like a reason for avoid exposing subtypes at all

[m-sasha]

It's not source compatibility that will be broken. Existing compiled code will throw an exception at runtime.

[MatkovIvan]

All of it is about possibilities and potential changes. Not a blocker at the moment I guess, we can discuss it when we'll really need this