Overlapping windows both receive clicks

[iffy]

I'm so excited for this library! Not sure if you're ready for pull requests or not yet, but if so I can try to fix this.

Bug is: if two subwindows overlapping, mouse click events happen to both. This video demonstrates dragging, but I've verified that button presses do it, too.

Monosnap.screencast.2026-04-08.21-15-39.mp4

[RowDaBoat]

Working on this, some comments:

It's not just windows! Silky using painter's algorithm means that when two controls are overlapping, either they both will receive hover & click mouse events (undesirable) or it must be consumed by the first one from the bottom (unintuitive).

Widgets can overlap due to off-layout positioning, extending on top of others (like dropdowns), and overlapping windows (this issue).

The only approach I can think of without introducing breaking changes is imitating Dear ImGUI:

• record the last frame's topmost widget as the 'hot' one (ie: use a counter to assign a per-frame id).
• in the current frame, propagate events only for the hot widget.
• reset the hot widget on user inputs that can generate state changes.
• provide a proc to reset manually for async state changes (changes that don't come from the user's input).

It has a one-frame delay, but keeps design intuitive and in immediate mode, even with this compromises.

[treeform]

Thank you for reporting this. We have fixed this! But we have other window handling things to do.

[RowDaBoat]

Details on #48 , will proceed to push final touches on hot/warm reset, and examples changing layouts tomorrow.