Re: On the pains of using child-frames / posframes

[martin rudalics <rudalics@gmx.at>]

 >> Not yet, for now I am only collecting and marking hacks and
 >> workarounds in the code. There are already many workarounds for bugs
 >> in child frames.

Please don't call the below "bugs in child frames".  Most of them are
bugs in window managers in the sense that these are either not IICC or
Freedesktop compliant.  It's a sad fact that the only window manager
correctly implementing child windows in that sense is that of Microsoft
Windows.

 >    The `no-accept-focus' frame parameter doesn't work reliably, e.g., it
 > doesn't work for me in Sway (a wayland window manager).  I've reported
 > that as a sway bug, and a sway dev told me that this is probably a bug
 > in their Xwayland implementation.  But he also said that the GTK
 > function gtk_window_set_accept_focus used by emacs to indicate that a
 > frame shouldn't receive focus in gtk builds is a no-op for wayland, and
 > that wayland doesn't really have a concept of non-focusable windows.  So
 > no-accept-focus will never work when emacs is built as a native wayland
 > application, i.e., with the pgtk branch.

I suspect that with Wayland the 'no-focus-on-map' parameter doesn't work
either as intended and a workaround for that would be needed too.  Could
you provide a simple option to hook into x_set_no_accept_focus and
x_set_no_focus_on_map and implement a functionality similar to that of
`corfu--popup-redirect-focus' so that we can avoid hooking into
`pre-command-hook'?  Maybe we should also separate the focus redirection
from the mouse click ignore functionality.

Also, please keep in mind that with Wayland the only frames we may be
able to reliably position on screen ourselves are child frames.  So any
functionality we implement here, may eventually become a functionality
for our normal (non-parented) frames there.

 >    With GTK builds and Gnome / Cinnamon, one needs the following hack to
 > make the child-frame resize properly:

`x-gtk-resize-child-frames' is an awful hack so I would really prefer to
not enable it out of the box on the indicated systems but rather provide
an optional value for `x-gtk-resize-child-frames' that does implement
that.

 >    Some workarounds against flicker, and a case in which the order of
 > setting a face attribute and setting the frame parameters makes a
 > difference for no obvious reason.

Are these flicker problems ...

 >      ;; Without the check, the frame flickers on Mac.

... typical for Macs or have people seen them elsewhere too?

 >    More flicker avoidance.

Don't we get something similar with `x-gtk-resize-child-frames'?  So
maybe we should provide a more general option that simply makes a child
frame invisible whenever people resize or move it?

 >    It seems like some overlays can make `posn-at-point' return wrong
 > y-values.

Is this `posn-at-point' behavior child frame endemic or has it been seen
with normal frames too?

 >    Also, the number of frame parameters one needs to apply for a typical
 > child-frame whose intent is to display completions, tooltips, or inline
 > help is quite large and nothing which one can write from the top of
 > one's head.

If you can provide a good name for this ...

 > (defvar corfu--frame-parameters

... like ...-child-frame-alist, I see no problems.  I never tried with
'width' or 'height' 0, though ...

 >    Ditto for the buffer one's going to display in the child-frame.

Who would apply a generalized version of ...

 > (defvar corfu--buffer-parameters

... - set_window_buffer?

 > This all looks to me as if child-frames should probably have some
 > dedicated API in vanilla emacs so that using them becomes a bit easier
 > and less verbose.  Also, that packages like corfu and posframe have to
 > duplicate each other's workarounds for several issues like the
 > unreliability of `no-accept-focus' doesn't seem right.  If there are
 > issues on certain supported platforms, those are better addressed in
 > emacs itself.

Please try to set up the above as you and Daniel see fit.  I hardly can
implement anything in this area - setting up a Gnome environment for
testing `x-gtk-resize-child-frames' was enough of a nightmare back then.

Thanks in advance, martin