GNU bug report logs - #57224
29.0.50; PGTK: scroll-bar obscures child-frame

Previous Next

To reply to this bug, email your comments to 57224 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

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

From: Florian Rommel <mail <at> florommel.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; PGTK: scroll-bar obscures child-frame
Date: Mon, 15 Aug 2022 17:15:00 +0200

[Message part 1 (text/plain, inline)]

In PGTK, child frames may be obscured by scroll-bars. This happens when
the scrollbar is added after the child frame is created (e.g. by
creating new windows, etc.). The bug may in particular affect people
using child-frame-based completion packages, such as corfu, company-
box, or company-posframe.

From what I could see in the code, in contrast to X, PGTK adds child
frames to the parent frame's edit_widget which is a GtkFixed (see "x-
create-frame"). A GtkFixed doesn't have any defined z-order behavior.
However, widgets seem to get drawn in the order of the internal child
list. Unfortunately, there is no direct way to insert widgets at the
front of this list or otherwise manipulate the list apart from pushing
children to the end or removing them. So a (dirty) workaround would be
to remove all children, add the scrollbar and then add all the removed
widgets again, see the patch.
A better solution may involve something like a GtKOverlay but I don't
know if that's practical in the current implementation.

To replicate the bug in 'emacs -Q':
(progn
  (make-frame
   `((title . "childframe")
     (parent-frame . ,(selected-frame))
     (border-width . 3)
     (internal-border-width . 3)
     (child-frame-border-width . 3)
     (vertical-scroll-bars . nil)
     (horizontal-scroll-bars . nil)
     (menu-bar-lines . 0)
     (tool-bar-lines . 0)
     (tab-bar-lines . 0)
     (minibuffer . nil)
     (undecorated . t)
     (left . 0.5)
     (top . 0.5)
     (width . 20)
     (height . 20)
     (left-fringe . 0)
     (right-fringe . 0)
     (background-color . "blue")))
(split-window-right)
(split-window-right))

[0001-Fix-scroll-bars-obscuring-child-frames-in-PGTK.patch (text/x-patch, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Florian Rommel <mail <at> florommel.de>
Cc: 57224 <at> debbugs.gnu.org
Subject: Re: bug#57224: 29.0.50; PGTK: scroll-bar obscures child-frame
Date: Tue, 16 Aug 2022 09:00:34 +0800

Florian Rommel <mail <at> florommel.de> writes:

> In PGTK, child frames may be obscured by scroll-bars. This happens when
> the scrollbar is added after the child frame is created (e.g. by
> creating new windows, etc.). The bug may in particular affect people
> using child-frame-based completion packages, such as corfu, company-
> box, or company-posframe.
>
>>From what I could see in the code, in contrast to X, PGTK adds child
> frames to the parent frame's edit_widget which is a GtkFixed (see "x-
> create-frame"). A GtkFixed doesn't have any defined z-order behavior.
> However, widgets seem to get drawn in the order of the internal child
> list. Unfortunately, there is no direct way to insert widgets at the
> front of this list or otherwise manipulate the list apart from pushing
> children to the end or removing them. So a (dirty) workaround would be
> to remove all children, add the scrollbar and then add all the removed
> widgets again, see the patch.
> A better solution may involve something like a GtKOverlay but I don't
> know if that's practical in the current implementation.
>
> To replicate the bug in 'emacs -Q':
> (progn
>   (make-frame
>    `((title . "childframe")
>      (parent-frame . ,(selected-frame))
>      (border-width . 3)
>      (internal-border-width . 3)
>      (child-frame-border-width . 3)
>      (vertical-scroll-bars . nil)
>      (horizontal-scroll-bars . nil)
>      (menu-bar-lines . 0)
>      (tool-bar-lines . 0)
>      (tab-bar-lines . 0)
>      (minibuffer . nil)
>      (undecorated . t)
>      (left . 0.5)
>      (top . 0.5)
>      (width . 20)
>      (height . 20)
>      (left-fringe . 0)
>      (right-fringe . 0)
>      (background-color . "blue")))
> (split-window-right)
> (split-window-right))

Thanks.  I don't think working around the problem by removing GTK
widgets is a particularly good idea, since we could always go down to
the GDK level and use gdk_window_lower (all children of a GtkFixed are
children of its GDK window, like most other GTK container widgets.)

I will look into that, because I think the same problem also exists on
X.

Previous Next

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