Re: Abysmal state of GTK build

[Po Lu]

"Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:

> Does this apply to pgtk as well?

PGTK has other problems on the input and selection side of things, and
shouldn't be used on X at all.  Try to select a large chunk of text in
the PGTK build running under X (xdisp.c immediately comes to mind), and
insert it into another program with Button2.  It will immediately crash
with an X Windows error.

> TBH, this whole thread sounds needlessly alarmist.

I'd have said the same until I actually started working on the GTK
build, which was in an even worse state several months ago.  For
example, because many people do not use toolkit widgets in Emacs
seriously, and GTK changes too quickly, a bug where moving the mouse
wheel on the scroll bar does nothing was not found in time to be fixed
in Emacs 28.

Seriously, folks, if you don't use the scroll bar enough to find such an
obvious bug, you might as well use the a build of Emacs with non-toolkit
scroll bars.

> The various GTK builds have been working fine for me and apparently the
> majority of emacs users on GNU/Linux. "Abysmal" does not describe that
> all all.

Okay, then please show another build of Emacs where opening Dired on a
relatively small frame prints warning messages to stdout, and
potentially resizes the frame to fit the menu bar.  Or resizing a frame
from the top left corner causes the bottom right corner of the frame to
lag behind the resize.

All of these might seem to be minor nuances, but they leave bad tastes
in users mouths.  The users then place the blame on us, and ask: "why
can't Emacs behave as nicely as other editors?"  (The answer is really
that the other editors use some other toolkit.)

> There have been grumblings about scenarios that GTK doesn't implement
> correctly or at all, and there were some big warning for that (there
> still may be). It seems we now emacs is adding a new such scenario
> (XInput2), while the GTK developers have lost some interest in X11 -- it
> seems we should just not enable XInput2 in that case.

It seems to me that the same crowd asking for various "modern" GTK
features also want features like pixel-scroll-precision-mode and monitor
refresh synchronization, which cause crashes or don't work on GTK.  We
are then blamed for the feature not working there as a result of bugs or
misdesigns in GTK.

In any case, there is no excuse for GTK to have buggy XInput 2 support,
considering that it used to be something that we did not support,
requiring various workarounds to explictly disable in GTK, and is
mentioned in the first few paragraphs of the GTK+ 2 to 3 migration
guidelines.

I only found out about this particular crash investigating bug#56879,
but there are many more issues, some of which are more insidious than
simple crashes.

> I'd actually hope we'd be able to do it _more_ with GTK, such as having
> GTK tabs, using the header bar, etc., where emacs currently looks rather
> antiquated.

Then we'd be dealing with GTK randomly resizing our frames to fit the
tab bar in addition to the menu bar.  Or the authors of the GNOME Human
Interface Guidelines declaring tab bars against the law at some point in
the future.  No thanks.