bug#45620: 28.0.50; Child frames should have their own border width and colour

[martin rudalics <rudalics@gmx.at>]

 > What customisations are you referring to? I cannot think of any
 > scenario, other than changing and reloading your theme, that could
 > change the settings of already present child frames.

Here I'm using a child frame for popping up the minibuffer with the
customization

(defcustom pop-up-mini-internal-border "blue"
   "Background of internal border of 'pop-up-mini-frame'."
   ...

and the form

   (set-face-background
    'internal-border pop-up-mini-internal-border pop-up-mini-frame)

to put it into practice when setting up such a frame.  This works fine
until I do M-x customize-face RET internal-border RET.  As soon as I
apply the value I customized there, my minibuffer child frame gets that
border instead of the one specified via 'pop-up-mini-internal-border'
above.

 >  > If I'm not mistaken we use that face for our tooltip frames too which
 >  > means one more conflict.
 >
 > Partially. On my system the internal-border colour and width only
 > applied to the top and left sides of the tooltip frame.

Yes.  I think there's a bug somewhere but the only time I tried to
locate it, I decided that someone else intentionally does it that way.

 > Packages do have the choice, they just have to make sure to override the
 > frame-local faces whenever they show something. The problem, as I see
 > it, is that they *have to* create a face to override the local
 > internal-border, instead of just having the option to do it, because
 > themes cannot offer a general setting, like an easily visible dark
 > border on a bright foreground, because they run into the frame margin
 > colour conflict like modus did in the linked issue. So if a package
 > doesn't overwrite the local internal-border your default look-and-feel
 > is a badly visible same-colour-on-same-colour popup.

Agreed.  On a historical note, I had to add the entire internal border
entertainment to child frames because neither gtk nor X bother to supply
the normal window manager border for them (Windows does) and so you can
neither make them stand apart easily nor can you resize them with the
mouse.  Implementing the latter from within Emacs was even very
entertaining.  I intentionally left the border color alone because I'm
convinced that customizing it is a bad idea as sketched in the above
scenario and packages should always try their own way to specify it.

 >  > So what should we do? Provide a separate 'child-frame-internal-border'
 >  > face and then probably also a 'tooltip-internal-border-face'?
 >
 > That would be perfectly good enough for themes like modus, yes.

Can you propose a patch?  Look at where we use INTERNAL_BORDER_FACE_ID
to set up a face (x_clear_under_internal_border in xterm.c is an
example), check f for child-frameness there and use the new face if the
frame is a child frame.  But be aware: Users like me will then have to
separately set the background for the child frame face so you might get
incompatibility complaints ...

martin