[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#48809: 28.0.50; Missing Lucid/GTK2 graphical elements on tiling WM
From: |
Basil L. Contovounesios |
Subject: |
bug#48809: 28.0.50; Missing Lucid/GTK2 graphical elements on tiling WM |
Date: |
Fri, 11 Jun 2021 13:02:10 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
martin rudalics <rudalics@gmx.at> writes:
>> Further to the tangent in bug#48229, the menu, tool, and scroll bars are
>> sometimes not drawn when creating new Lucid/GTK2 frames under the tiling
>> WM Xmonad. The missing elements reappear after the affected frames are
>> resized.
>>
>> I cannot reproduce any of these issues with GTK3/PGTK, but the Lucid
>> behaviour is present since at least Emacs 24.5.1 (I don't have old GTK2
>> builds at hand). Affected Emacs 28 configurations follow my signature.
>
> Thanks. The only thing that is evident from your examples is that only
> toolkit elements are affected. Elements Emacs draws itself are not
> missing in your examples. I suppose the behavior you see happens
> because Xmonad rejects a first size proposal of Emacs for these elements
> and does not draw them, notifies Emacs that it wants different sizes for
> these elements and that notification gets lost - somehow and at least
> sometimes. I have no good explanation why things work with GTK3 and not
> with GTK2 though. Are all behaviors you reported reliably reproducible?
Yes, 100% reliable/deterministic AFAICT, at least in my current setup.
> One thing I'd like to exclude is that this is yet another instance of
> Tom Gillespie's observation that Emacs does not play well with window
> managers that do not set _NET_WM_STATE. x_get_current_wm_state
> apparently fails on such systems and we probably never (or at least not
> always) get a not_hidden frame in the MapNotify case and have to wait
> for a ConfigureNotify instead (which your remark about the reappearance
> of missing elements after resizing would confirm).
>
> To check this please do (setq frame-size-history '(100)) and proceed
> with some of your broken behaviors. I'd be interested if when you then
> do (frame--size-history) and look into the *frame-size-history* buffer
> you can see
>
> "MapNotify, not hidden & not iconified"
Correct:
0. emacs -Q
1. (setq frame-size-history '(100)) C-j
2. C-x 5 2
[The left scroll bar of the unselected frame is now missing.]
3. (progn (frame--size-history)
(pop-to-buffer-same-window "*frame-size-history*"))
C-x C-e
This gives the following with Lucid, GTK2, and GTK3, respectively:
lucid.txt
Description: Lucid frame size history
gtk2.txt
Description: GTK2 frame size history
gtk3.txt
Description: GTK3 frame size history
> entries. Alternatively, you could set a watchpoint at xterm.c's
>
> bool not_hidden = x_get_current_wm_state (f, event->xmap.window,
> &value, &sticky);
>
> and see whether a value of true is ever returned.
Also confirmed.
> One thing you could try is to change
>
> if (v == 1 && f->visible != 1)
> redisplay_other_windows ();
>
> to
>
> if (v == 1)
> redisplay_other_windows ();
>
> in frame.h's SET_FRAME_VISIBLE so maybe Emacs would send the modified
> elements (modified because the WM changed their size to something Emacs
> didn't ask for) again. Honestly, I have no hope that this would help.
Unfortunately it doesn't (at least not with Lucid).
Thanks,
--
Basil