GNU bug report logs - #75056
31.0.50; tty-child-frames with server / multiple clients possible hangs

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>, Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: lenbok <at> gmail.com, 75056 <at> debbugs.gnu.org
Subject: bug#75056: 31.0.50; tty-child-frames with server / multiple clients possible hangs
Date: Sun, 26 Jan 2025 09:53:19 +0100

>> Martin mentioned in passing that he thinks iconifying frames on ttys
>> should perhaps do something. So it's maybe a "not yet".
>
> What could that "something" possibly be?  Martin?

See the option 'iconify-child-frame'.  We have to explain its semantics
for tty child frames: The two obvious choices are to either do nothing
or make the child frame invisible.

>> Yes. C-x 5 2 can make a new root frame, and only one is visible on
>> the display.
>
> So only the top root frame now returns visible = t?

What is the "top root frame"?  Have we defined it somewhere?

>> raise-frame is make-frame-visible + changing z-order, make-frame-visible
>> and make-frame-invisible change the "visible" flag. (Just notices
>> make-frame-visible talks about "X window", hm.).
>>
>> Did you mean these doc strings should be changed, too, or did you mean
>> something else?
>
> I wanted first to understand what happens with this on TTY frames.
> Then we'd need to update the doc strings and also the manuals.

I still wonder what happened to the "when one frame completely obscures
another" visibility state issue.  Has that vanished?  IIUC it would make
a child frame (and possible even a root frame) practically invisible
when no part of its drawn by redisplay.  On a GUI the WM would decide
that and we don't have to care (IIRC we did care on Windows in the past
- at least when debugging).

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.