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: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 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: Fri, 31 Jan 2025 11:02:01 +0100

martin rudalics <rudalics <at> gmx.at> writes:

>> There is little chance that I can change how the borders are drawn, I'm
>> afraid. I started with trying to give tty frames a border_width, and
>> failed spectacularly. It was so bad that I git reset --hard in a rage,
>> which is a really rare event.
>
> What were the problems?

TTY frames not having borders seems to be an implicit assumption
"everywhere", frame matrix sub-allocation, mouse, menus, you name it.
That was simply too much for me after hours of trying. Maybe someone
else with more patience could try again.

>>> Looks good.  But _where_ on earth (that is, in the code) do you that and
>>> how is it related to the width of the internal border?
>>
>> See copy_child_glyphs.
> [...]
>> The code is not related to an internal border, and I'm relatively sure
>> tty frames don't have one right now. At least as far as redisplay is
>> concerned, don't know about the frame parameters/values. It's like for
>> border_width.
>
> I see.  Your approach is simple but relies on the fact that you draw
> frames using a painter's algorithm.  The decoration of a frame above (in
> z-order) obscures the contents (and maybe also decorations) of the
> frames beneath.

Right. Simple. dumb, good :-)

> Basically, what you do is to draw an outer border.  

Yes, I'm playing the window manager.

> For mouse-resizing frames we can easily expose that outer border to
> Elisp. But the problem is with the coordinates. An outer border should
> belong to its frame and not the parent. Clicking an outer border with
> the mouse should activate its frame and not the parent. We can fix
> these as well but it will be a bit contrived.

No comparison with introducing borders for tty frames :-).

>>> One bug I noted now is the following.  Do C-l and M-l and drag the
>>> yellow and orange frames somehow as in before.png with the cursor in the
>>> yellow frame right before the left edge of the orange frame.  Do C-f -
>>> the cursor appears on top of the left edge of the orange frame as in
>>> middle.png.  Another C-f moves it into the orange frame as in
>>> after.png.
>
> Note that this is a bug in the cursor setting method.  I'm not sure
> whether it's been there ever since or was introduced by your recent
> changes.  In either case, please have a look.  You don't need my changes
> to reproduce it but it's much easier when you can drag child frames
> around.

I'll take a look, need to find some time.

Previous Next

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