I’m hiding the titlebar in my decorated compose wi...
# compose-desktop
r
I’m hiding the titlebar in my decorated compose window using Win32 APIs, but am running into issues with drag and resize when using Compose inside the window. The issue is that the ComposePanel is consuming all clicks. It doesn’t allow clicks to pass through to the window itself. This means that clicks that should be going to the window’s “NonContent” area (i.e. the frame) are being consumed by compose, and this means that window resizing, dragging etc. do not work. Does anyone know if there’s a way to address this (even if it’s hacky)?
i
Compose already implements it out of the box for undecorated AWT windows. It's done manually with handling input inside compose content. If the provided window class doesn't work for you (why?) you can just re-use this code. See
UndecoratedWindowResizer
class - https://github.com/JetBrains/compose-multiplatform-core/blob/jb-main/compose/ui/ui[…]topMain/kotlin/androidx/compose/ui/awt/ComposeWindow.desktop.kt
m
I assume they want the native window frame, just without the title bar
r
Yep, I want the native window frame. The problem with using things like “UndecoratedWindowResizer” is that they don’t integrate with the window manager properly, so things like “snap” don’t work.
I ended up solving this by writing a custom integration with ComposeWindow, though I feel this should be part of the library because it takes a lot of care to get things working right without bugs, e.g. getting “snap layouts”, animation and accessibility to work. I had to effectively punch a hole in the SunAwtCanvas (via a WindowProc) to allow clicks to reach the main window behind, as well as communicating the locations of my custom window controls+titlebar region back and forth to a WindowProc on the main window. It looks like the Jetbrains products using JBR do all this work, too?
m
I have a similar issue, I am using undecorated windows in my app and snapping doesn't work. It seems that Compose doesn't actually start a window drag, but just changes the window position with mouse movement, so it ignores all the OS handling.
r
Right. It should be responding with
HTCAPTION
when the window is hit tested and letting the OS handle window movement.
111 Views