Re: Abysmal state of GTK build

[Lynn Winebarger]

On Mon, Aug 22, 2022 at 8:12 AM Po Lu <luangruo@yahoo.com> wrote:
> "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl> writes:
> > TBH, this whole thread sounds needlessly alarmist.
I use the GTK build, and I've experienced the occasional odd crash
with messages indicating there was a problem in GTK.  I don't even use
X forwarding.

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

I have no expertise in implementing graphical interfaces, but as a
user I prefer applications to make use of the styling/interface
behavior from the main GUI, at least if I'm using something like
GNOME/KDE/XFCE.  That's part of *why* you choose such a GUI.  If the
interface is too dissonant with what I expect, I probably won't notice
whether something like "pixel-scroll-precision-mode" exists.

> 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.
It seems like you're missing the point.  If I'm a user of GNOME after
they do that, it probably means I am ok with prohibiting tab bars.  Or
I shouldn't be using that version of GNOME.  The choice of GUI
implicitly signals user preferences about the features they want and
don't want.  What's the issue with deferring to that?
That Haiku interface sounds interesting. It would be nice to have an
Emacs that cooperates with the GUI model of events via threaded
processing, instead of insisting on the same basic event loop used for
terminal-based interaction.
Of course, it's not like I'm offering to do any development.  It's not
really my area.

Lynn