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

Previous Next

Full log

Message #368 received at 75056 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#75056: 31.0.50; tty-child-frames with server / multiple
 clients possible hangs
Date: Sun, 02 Feb 2025 20:39:05 +0100

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

>> Also, moving child frames is pretty nice too!
>
> The attached patch now also resizes child frames by dragging their edges
> or corners.  One thing that does not work is that when another child
> frame is beneath an edge, Emacs selects the child frame beneath the edge
> before I can start dragging.  I think that frame/child frame selection
> with the mouse is not perfect in the current state in three regards:
>
> - When I do down-mouse-1 in the non-selected root frame, Emacs does
>   'mouse-set-point' there.  I think it should do so only for a mouse-1
>   so I can back out before releasing the mouse button and obviously use
>   the down-mouse-1 for dragging.
>
> - When I have two overlapping child frames and do down-mouse-1 on a
>   border of the frame above and that border covers the frame beneath,
>   Emacs should never select the frame beneath here.  Not even after I
>   release the button.
>
> - Clicking into a child frame anywhere but on a bar does not select it.
>   This is uncomfortable and at least does not mimic the behavior of GUI
>   frames on all window managers I know.
>
> I'll look into these tomorrow.  Pointers welcome.

Thanks!

Works well for me. Only dragging the edges of a child frame doesn't seem
to work like in a GUI.

With the mouse bindings I'm afraid I can't help much. I agree that the
current use of down-mouse-N is generally not such a great idea. Example:
menus on the mode-line. The default binding of down-mouse-1 for opening
the menu is a PITA for trackpad users using tap-to-click, and prevents
keyboard interaction with the menu because lifting the finger closes the
menu.

Likewise, it would be nice if one could drag the child frames without
having to hold the finger pressed on the trackpad. (In contrast to
dragging a region, which can be done with a 3-finger drag.) Very
inconvenient, and a bit inconsistent.

How that all is currently wired is a bit of a mystery to me. There are
a number of keymaps involved, and it is unclear to me which exact
purpose each one has, and where mouse key bindings are exactly put in
and why: input-decode-map, function-key-map, key-translation-map,
global-map, maybe others?

Previous Next

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