bug-gnu-emacs
[Top][All Lists]
Advanced

[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:

Attachment: lucid.txt
Description: Lucid frame size history

Attachment: gtk2.txt
Description: GTK2 frame size history

Attachment: 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]