Re: Abysmal state of GTK build

[Dirk-Jan C. Binnema]

Thanks for the detailed response.

On Monday Aug 22 2022, Po Lu wrote:

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

So it does not apply to pgtk on Wayland? What about on X?

I don't use X, but I can't remember problems copy-pasting between other
Gtk program (say, GEdit and gnome-builder). What is emacs doing
differently?

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

I've seen some old grumblings and apparently some new problem with
Xinput2-related code. But I've been happily using gtk-based emacs since
20 years or so? So, I find it strange if it suddenly changed to
"abysmal" and selected for immediate demotion to be non-default.

> 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'm not seeing any of that. What about Gimp & Inkscape -- don't they
support Xinput2?

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

There are always excuses for bugs of course :-) In this case it seems
that emacs exercises some old code in new ways, while the maintainers
are concentrating on Wayland. 

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

E.g. tab-usage like Gedit or Gnome Builder do it, would be a great
visual improvement IMHO. Or even Firefox's (which implemented their own
tabs I think?).

Anyway, thank you for your work... it is appreciated.

Kind regards,
Dirk.

-- 
Dirk-Jan C. Binnema                  Helsinki, Finland
e:djcb@djcbsoftware.nl           w:www.djcbsoftware.nl
gpg: 6987 9CED 1745 9375 0F14 DA98 11DD FEA9 DCC4 A036