Re: macOS child frame lower behavior

[martin rudalics]

> It apparently means the entire screen list on the desktop.

Sounds bad (though I have no idea what "screen list" stands for).

> AFAICT, at least in Emacs, it does not do what is described. I created
> two child frames and attempted to restack them so that the second
> created one was above the first. This seemed to have no effect.

I see.  The code works here as intended with a GNUStep build (under
Debian's xfwm) so the problem is not on the Emacs side.  Does
'raise-frame' with two child frames work as intended?  What happens when
you have two overlapping child frames and you click into the lower one?
Does it raise to the top?  IIUC the following setup (which works here)
would fail: Make two normal frames A and B with A overlapping B and on B
make two child frames C and D where C overlaps D.  If you now in frame A
evaluate (raise-frame D), does as a side-effect B overlap A?

If we cannot fix that in some other way, we should probably make
lowering a child frame a NOOP on MacOS when it is the sole child frame
of its parent.  If there are two child frames, we could try to raise the
other one, if that works somehow.  For more complicated situations, we'd
have to look whether there exists a z-order for child frames and use
that.

martin