A modern programming language that makes developers happier.

kotlinlang

Is there anything built-in for bringing a window to the front?

I'm trying to build some logic to either (a) open a specific window, or (b) bring that window to the front if it's already open.

• I can toggle alwaysOnTop on/off to achieve this, but that feels unacceptably hacky.
• I can also use Swing to do this from inside the window where I have a handle (e.g. `window.toFront()`), but I'd like to achieve a design where the window isn't responsible for bringing itself to the front

Keep a list of windows you have open and call `toFront()` on it when you need

I have something like this:
```    /**
     * Shows the settings window on the given pane.
     */
    fun showSettingsWindow(pane: SettingsPane = SettingsPane.Default) {
        when (val state = settingsWindowState) {
            is SettingsWindowState.Closed -&gt; settingsWindowState = SettingsWindowState.Open(pane)
            is SettingsWindowState.Open -&gt; {
                state.pane = pane
                state.window?.toFront()
            }
        }
    }


    /**
     * Closes the settings window.
     */
    fun closeSettingsWindow() {
        settingsWindowState = SettingsWindowState.Closed
    }```

and in `SettingsWindow` I have
```Window(...) {
     LaunchedEffect(state, window) {
         state.window = window
     }
}```

Thank you! That approach makes sense, though I don't *really* like passing a window reference up to its parent. Feels counter to the design of the `Window` composable, where things for the parent to use are passed in (e.g. `rememberWindowState`).

I ended up making a minimal `BringToFrontRequester` which can be passed to the window, which then binds to it. Much like a FocusRequester.

Something like that, yes. I have a `WindowManager` object responsible for all the windows in the app.

You can still pass the state object to Window; you just need to add a `window` property to it.

You're right, I suppose "communicating up" already happens with the WindowState, e.g. setting the size/position. So it wouldn't be an anti-pattern to populate a nullable on the state