Re: Question about üarent-frame changes

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

[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]

martin rudalics <rudalics@gmx.at> writes:

>> The biggest problem for me in this area today is that "visibility" on
>> GUIs and ttys apparently is not the same thing. For example,
>> make-frame-visible seems to do nothing for tty frames. So I guess all
>> tty frames are always visible in the sense that frame::visible is
>> non-zero.
>
> You mean because 'suspend-tty' acts on top-level frames only?

Haven't looked at suspend-tty yet. The list grows and grows :-).

No, the problem is that the whole hide/show frames is not implemented on
ttys presently. But I think I need that to work as it does on GUIs to be
compatible with existing packages like Corfu, which uses that.

Which means I have to implement hide/show on ttys like it is on GUIS,
amd handle the "obscured" case differently. Not sure sure if it needs a
bit in the frame at all, FWIW, since we know the topmost frame root
frame on a tty anyway, which is the only one that is visible. Anyway.
Doesn't look like a lot of fun :-).

> Another issue we would have to resolve in some way is whether a child
> frame should (or could) be given input focus on TTYs: That is, whether a
> user may type "into" a child frame, for example, when an application
> issues a 'yes-or-no-p' question within a child frame equipped with a
> minibuffer window.

My aim is to let tty child frames act like their GUI counterpart as far
as possible, which seems to mean that child frames act like any other
frame for the most part.

And that's the case currently with what I have so far. Opening a child
frame is like C-x 5 2, only that the child is displayed on top of its
parent and so on. The child can have a minibuffer and everything else.
(Except for the menu bar thing we talked about, I deliberately turned
that off).

In the y-or-n-p case, this looks like this


[-- Attachment #2: Screenshot 2024-09-19 at 11.05.56.png --]
[-- Type: image/png, Size: 445852 bytes --]

[-- Attachment #3: Type: text/plain, Size: 887 bytes --]


That is with

(defun emacs-user:my-make-child ()
  (interactive)
  (make-frame `((parent-frame . ,(selected-frame))
		(background-color . "gray10")
		(foreground-color . "white")
		(top . 15)
		(left . 40)
		(width . 80)
		(height . 25))))

So it's a "normal" frame. Haven't gotten to minibuffer-only frames and
what else is possible. (TIL there is also a delete-after or so frame
parameter). There is probably something lurking there as well.

>> But that would be too easy of course, which is why frame::visible has 2
>> bits, and if the second bit is set the frame is "obscured" (happens with
>> C-x 5 2), which I'd call sort of invisible because it can't be seen but
>> that's of course naive.
>
> Wasn't that second bit used exclusively for redisplay purposes and as
> such not available to Lisp code?

That's true, but the whole rest of hiding/showing frames isn't there on
ttys.