Commit 70678906 authored by Martin Rudalics's avatar Martin Rudalics
Browse files

* etc/PROBLEMS: Mention GTK+ problem with unexpected frame widenings

parent a5dcc97b
......@@ -969,6 +969,33 @@ Emacs, for example (from a Posix shell prompt):
*** Emacs built with GTK+ toolkit can unexpectedly widen frames
This resizing takes place when a frame is not wide enough to accommodate
its entire menu bar. Typically, it occurs when switching buffers or
changing a buffer's major mode and the new mode adds entries to the menu
bar. The frame is then widened by the window manager so that the menu
bar is fully shown. Subsequently switching to another buffer or
changing the buffer's mode will not shrink the frame back to its
previous width. The height of the frame remains unaltered. Apparently,
the failure is also dependent on the chosen font.
The resizing is usually accompanied by console output like
Gtk-CRITICAL **: gtk_distribute_natural_allocation: assertion 'extra_space >= 0' failed
It's not clear whether the GTK version used has any impact on the
occurrence of the failure. So far, the failure has been observed with
GTK+ versions 3.14.5 and and 3.18.7.
Some window managers (xfce) apparently work around this failure by
cropping the menu bar. With other windows managers, it's possible to
shrink the frame manually after the problem occurs, e.g. by dragging the
frame's border with the mouse. However, some window managers have been
reported to refuse such attempts and snap back to the width needed to
show the full menu bar (wmii) or at least cause the screen to flicker
during such resizing attempts (i3, icewm).
*** Metacity: Resizing Emacs or ALT-Tab causes X to be unresponsive.
This happens sometimes when using Metacity. Resizing Emacs or ALT-Tab:bing
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment