Re: Q: child frames on ttys

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 30 Aug 2024 11:17:12 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
>> From: martin rudalics <rudalics@gmx.at>
>>
>>  > (Background is of course that I'm trying to assess how much work is
>>  > ahead, and if I want to do it :-).
>>
>> I suppose that visibility and restacking of child frames and size
>> changes of child frames and their ancestors are the corner issues.  Once
>> these have been resolved, the code should be pushed and you should wait
>> for user feedback.
>>
>> Many thanks for lifting the "Note that child frames are meaningful on
>> graphical terminals only." restriction, martin
>
> Another feature to test with child frames on TTY displays is menus,
> both from the menu bar and popup menus.
>
> From where I stand, features that are perhaps hard to implement for
> child frames on TTY displays could be documented as unsupported, and
> could either do nothing or signal an error.  IOW, we don't have to
> support everything on TTY frames in this regard, if doing so is
> currently hard or impossible.  The feature, even if limited, is still
> useful enough, from my POV.

I think I have such a possible restriction where I'm aplit if it
would be acceptable or rather not: Suppose one could not change named
faces on tty chld frames. That is, for example, child frames would
always use the same default, mode-line, etc face as the root frame. And
as a consequence, the color frame params would have no effect.

The reason for that is that I copy struct glyphs from child matrices to
the root matrix. Glyphs contain face ids, so there needs to be a
function mapping face ids of the child frame to face ids on the root
frame.

The simplest such function is of course the identity function, which
means child and root share the same face cache. With the consequence
that changing named faces on the child modifies faces of the root. Not
nice, but simple.

As I said, I'm not sure about this. I could also think of redefining the
concept of face id to something containing the frame or cache holding
the face's definition. Which could be done in more than one way. And so
on, but it's certainly some work.

What do people think?