Re: Abysmal state of GTK build

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Mon, 22 Aug 2022 20:10:16 +0800
> 
> > 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.

What is your opinion on defaulting the GTK build to be without
XInput2?  Since that option causes crashes, it sounds to me like a
good compromise to leave the GTK build (by default) without the
XInput2 niceties, providing an opt-in configure-time switch to use
XInput2.  This will allow people who don't mind an occasional crash,
or can avoid that procedurally, to have the XInput2 features, while at
the same time protecting the innocent.