[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#57224: 29.0.50; PGTK: scroll-bar obscures child-frame
From: |
Po Lu |
Subject: |
bug#57224: 29.0.50; PGTK: scroll-bar obscures child-frame |
Date: |
Tue, 16 Aug 2022 09:00:34 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Florian Rommel <mail@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.