A way to query z-order of windows in xplat manner (or one of listed alternatives)

Is your feature request related to a problem? Please describe.

I was delevoping docking control similar to @wieslawsoltes docking lib but with ability to drag drop outside window and into other windows and thats where my problem is. It is very difficult to reliably check which window should be docked into when they are stacked together on top of each other.

Describe the solution you’d like

Something like z-order but i dont care how or in what data shape i get this information. It doesnt have to be ZIndex (doesnt work on Windows anyway).

It can be a bool or method that checks if window/control is truly visible for a given point

or a method that will give me control/window under given point with respect to visibility for that point (so GetVisualAt will NOT work for me since it disregards visibility for given point)

or a method that enumerates windows in ordered manner (either from top-most or bottom-most from visibility standpoint).

For my case checking transparency of window for given point is not necessary just something nice to have in case someone really want (semi)transparent windows

The only limit is i want to avoid interop code.

And i cant rely on enter/leave events because i will need this info while already dragging something.

Describe alternatives you’ve considered

I used something like Stack then removed and put back window on focus gained but thats unpleasant since i had to make ALL windows to subscribe to this event even those created dynamically and since im working on library that was potentially error prone for users.

Also it turned out to be unreliable. For some configurations it worked fine but based on order of focus gained and order of drag&drop (eg. window1 -> window 2 or window2 -> window1) it can malfunction so i would like something more reliable

[grokys]

The API on macOS is NSWindow.orderedIndex.

[BreyerW]

@maxkatz6 @grokys recently i realized i might try to use color coding technique (which is fairly popular algorithm as 3d picking solution just never occured to me i could try to use it on windows to ensure easier porting between OSes) and tried prototyping it with high-level Avalonia API.

But i encountered few issues on high-level API: mouse event time resolution seems to be lower than rendering time resolution in high-level code resulting in color codes being desynced with mouse position (which i used to calculate where to put adorn layer) when moving fast with mouse. If i decided to simply cover entire window then it would be very visible to user since screenshot needs to actually see changed color and thus enabling adorn for single frame doesnt seem to work.

So im wondering is there a way in low-level API to redraw selected or all windows off-screen, preserving visible order? In this scenario i dont need to know zindex directly as long as OS will redraw all windows orderly for me then read framebuffer or whatever back and i only need to do it when actually entering new intersecting windows which means perf likely wont be a problem esp since i can disable all controls for offscreen re-render and only render color-coded background

if not then i guess i will ditch Wayland and be done with this.