Re: Abysmal state of GTK build

[Po Lu <luangruo@yahoo.com>]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Well, let me qualify that a bit: I think if we can make the default
> non-Gtk toolkit version of Emacs pretty enough (and usable enough for a
> reasonable user), and have compelling reasons to discourage the
> Gtk-toolkit version (I think the _exit when a display shuts down, and
> the XInput2 problems, might be compelling), then we might convince them.

Prettyness is hardly useful when the software itself crashes.

Especially with the modern idea of "pretty", which is rounded corners,
low-contrast icons, animations and blur.  Aside from that, the GTK build
already has enough compelling problems for almost anyone to switch from
it, just look at this part of etc/PROBLEMS:

  *** 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.4.2, 3.14.5 and 3.18.7.  However, another 3.4.2 build
  does not exhibit the bug.

  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).

  See also https://debbugs.gnu.org/cgi/bugreport.cgi?bug=15700,
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22000,
  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22898 and
  https://lists.gnu.org/r/emacs-devel/2016-07/msg00154.html.

That bug is particularly nasty.  I tried my best to get rid of it, but
it still pops up once in a while, usually when the user switches to a
Dired buffer, which has a very long menu bar.  Despite the frame being
maximized on some window managers, which is probably very annoying.

I think the reason users use the GTK build despite those problems is
because it is the default, and they don't know any better.  Then,
because they assume that the developers of a major toolkit are better at
their job than us, blame for the resulting problems is assigned to
Emacs, which results in shouting on the bug tracker.

In the meantime, we have to endure the low-quality work of the GTK
developers, in whose world files cannot be saved after the window server
is shut down, and users and developers who turn off GTK mis-features are
"clowns", "the internet peanut gallery", and have their knobs yanked out
from underneath:

  https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4829

> But without the 1-5) I outlined, I don't think there's any chance
> what-so-ever.

Were they fine with the Lucid build before the GTK build became the
default?