macOS child frame lower behavior

macOS child frame lower behavior

[Aaron Jensen]

Hi,

I recently filed this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41422

I was curious if this behavior is expected and/or known. It doesn't
fit the docs, but it could be a limitation of macOS. I know child
frames have differences from OS to OS.

Aaron

Re: macOS child frame lower behavior

[martin rudalics]

 > I recently filed this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=41422
 >
 > I was curious if this behavior is expected and/or known. It doesn't
 > fit the docs, but it could be a limitation of macOS. I know child
 > frames have differences from OS to OS.

It is not the expected behavior and AFAICT it behaves on GNU/Linux and
Windows as described in our docs.

Note that, for example, the description of the XLib manual says about
XLowerWindow (which we call from x_lower_frame)

   The XLowerWindow() function lowers the specified window to the bottom of
   the stack so that it does not obscure any sibling windows.

and that of gdk_window_lower (which we do not call currently but would
have to call in a "pure" GTK build for non-X systems) says

   Lowers window to the bottom of the Z-order (stacking order), so that
   other windows with the same parent window appear above window.

I cited these because I expect the corresponding method called by
ns_lower_frame (orderBack) do the same.  According to its doc

   Moves the window to the back of its level in the screen list, without
   changing either the key window or the main window.

it should but that depends on what "level on the screen list" precisely
means.

If it doesn't do the same, we likely have a bug but I cannot check that
here.  Maybe you can try to find out what ns_lower_frame does on your
system.  And maybe you can tell us whether 'ns-frame-restack' behaves as
documented too.

Thanks, martin

Re: macOS child frame lower behavior

[Aaron Jensen]

On Thu, May 28, 2020 at 12:04 AM martin rudalics <rudalics@gmx.at> wrote:
>    Moves the window to the back of its level in the screen list, without
>    changing either the key window or the main window.
>
> it should but that depends on what "level on the screen list" precisely
> means.

It apparently means the entire screen list on the desktop. If you
lower a child frame, the only way to actually lower it (because it's
attached to the stacking context of the parent) is to lower the
parent, or so macOS thinks.

> If it doesn't do the same, we likely have a bug but I cannot check that
> here.  Maybe you can try to find out what ns_lower_frame does on your
> system.

It appears to do what Emacs is doing, which is the incorrect
behavior--it hides the parent window. Here's a minimal repro without
Emacs:

https://github.com/aaronjensen/child-frame-order-back-repro

>  And maybe you can tell us whether 'ns-frame-restack' behaves as
> documented too.

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.


Aaron

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

Re: macOS child frame lower behavior

[Aaron Jensen]

On Thu, May 28, 2020 at 9:54 AM martin rudalics <rudalics@gmx.at> wrote:
>
>  > It apparently means the entire screen list on the desktop.
>
> Sounds bad (though I have no idea what "screen list" stands for).

Yeah, I just read it as list of windows, but who knows if that's
actually what it means.

>  > 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?

No, it focuses the frame raised, but does not change its layering.

> What happens when
> you have two overlapping child frames and you click into the lower one?
> Does it raise to the top?

No, it does not.

> 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?

Yes, whatever is done to a child actually impacts the parent.

> 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.

If you remove a child and re-add it, you can change the order, which
works for raise_frame, because when you add the child frame back it
gets added as the top-most. I don't know how to emulate a lower_frame
short of removing all of the children and then re-adding them in the
proper order (with the one being lowered first). Here's an example of
that working:

https://github.com/aaronjensen/child-frame-order-back-repro

Specifically: https://github.com/aaronjensen/child-frame-order-back-repro/blob/master/ChildWindowTest/ChildWindowController.m#L24-L47

Aaron

Re: macOS child frame lower behavior

[martin rudalics]

 >> 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?
 >
 > No, it focuses the frame raised, but does not change its layering.
 >
 >> What happens when
 >> you have two overlapping child frames and you click into the lower one?
 >> Does it raise to the top?
 >
 > No, it does not.

Both of these sound pretty grave.  Would changing the visibility of
child frames help to work around these?

 >> 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?
 >
 > Yes, whatever is done to a child actually impacts the parent.

So in this scenario D would _not_ appear on top of C while B appears on
top of A?

 > If you remove a child and re-add it, you can change the order, which
 > works for raise_frame, because when you add the child frame back it
 > gets added as the top-most. I don't know how to emulate a lower_frame
 > short of removing all of the children and then re-adding them in the
 > proper order (with the one being lowered first).

Is such redrawing a chain of child frames visually noticeable?  Would it
work to make them all invisible first and then make them visible in the
proper order or do you have to unparent them first and then reparent
them in the proper order?

martin

Re: macOS child frame lower behavior

[Aaron Jensen]

On Thu, May 28, 2020 at 11:45 PM martin rudalics <rudalics@gmx.at> wrote:
> Both of these sound pretty grave.  Would changing the visibility of
> child frames help to work around these?

AFAICT, orderOut is how you hide windows, which appears to remove
parentage anyway.

>  >> 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?
>  >
>  > Yes, whatever is done to a child actually impacts the parent.
>
> So in this scenario D would _not_ appear on top of C while B appears on
> top of A?

Right, it appears to be impossible to reorder child frames while using
raise-frame or lower-frame.

>  > If you remove a child and re-add it, you can change the order, which
>  > works for raise_frame, because when you add the child frame back it
>  > gets added as the top-most. I don't know how to emulate a lower_frame
>  > short of removing all of the children and then re-adding them in the
>  > proper order (with the one being lowered first).
>
> Is such redrawing a chain of child frames visually noticeable?  Would it
> work to make them all invisible first and then make them visible in the
> proper order or do you have to unparent them first and then reparent
> them in the proper order?

It is visually noticeable only in that the layering changes, which is
the desired effect. Making them invisible and then reparenting them
(since you can't just make them visible again as far as I can tell)
appears to be strictly worse in that it causes focus to change since
any window that is orderOut'd loses focus.

Aaron