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
>> The root_frame of the old top frame is the old top frame itself. Or am
>> I missing something?
>
> Maybe. Make a child with M-l, then in the child
>
> (frame-parent (tty-top-frame)
> => F1
>
> It's 1:1 the display info's top_frame. IOW, I left the setting of
> top_frame as is was before, only that there are now child frames to
> which it gets set.
What I meant was that currently with
(setq F1 (selected-frame))
(setq F2 (make-frame))
(next-frame)
(frame-visible-p F1)
the last form evaluates to t. But if we change 'frame-visible-p' to not
always return t if the argument frame is a tty frame, the above will
give nil IIUC. And that's not what happens on a GUI.
>> I think we should use the metaphor of a top frame on a tty as that of a
>> maximized frame on a GUI. Such a frame hides all other normal frames on
>> that workspace but does not render them invisible or iconified (I ignore
>> z-order and groups here).
>
> That's not so in the current code. And why should it be so complicated?
> Either I can see a frame or not.
Be aware that it will change the current behavior for top frames and
make tty frame handling different from what it is on a GUI.
> It's much easier for me to think about if this second concept of being
> obscured does not exist. And it's easier in redisplay: If it's visible
> display it, otherwise don't.
The question is not whether to display it if it's not visible. The
question is whether Lisp code should consider it as visible.
martin
This bug report was last modified 110 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.