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

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Florian Rommel <mail <at> florommel.de>
Cc: 57224 <at> debbugs.gnu.org
Subject: 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.