Re: PGTK-related misconceptions

[Dirk-Jan C. Binnema]

On Friday Apr 15 2022, Po Lu wrote:

> Morgan Smith <morgan.j.smith@outlook.com> writes:
>
>> I'd like to report that my super key stopped registering.  I suspected
>> commit 1404e16975 caused it so I did a quick `git revert 1404e16975`
>> ontop of 807682de1e and that fixed it.
>
> Crystal ball says you are using X Windows, and have to put
>
>   remove mod4 = Hyper_L
>
> in your ~/.Xmodmap file, because GTK doesn't try as hard as regular X11
> Emacs to work around the common kind of virtual modifier
> misconfiguration.
>
> People using X should _never_ use PGTK.  The regular X build does a much
> better job at supporting that than PGTK ever will.
>
> It is completely pointless to put up with half-working child frames,
> random keyboard-related lossage, random frame placement/resizing
> failures, so the actual fix is to delete `--with-pgtk' from your calls
> to configure.
>
> Similarly, people building packages with PGTK enabled that are labeled
> "enhanced" are doing their users a disservice.  No packager should
> enable PGTK by default, and every package should ideally come with a big
> disclaimer warning against using PGTK on window systems otherwise
> supported by Emacs, since time and experience shows that Emacs generally
> does a much better job at their support than GTK.
>
> Many people are also being mislead by articles on the internet claiming
> that PGTK leads to faster redisplay, such as this one:
> http://www.cesarolea.com/posts/emacs-native-compile
>
> That is not true, since regular Emacs with cairo uses more-or-less the
> same rendering path as PGTK, except when PGTK runs on Wayland, where it
> uses software rendering and does image compositing in software, and is
> thus slower than everything else.  Scrolling on PGTK is also not as
> efficient as XCopyArea requests.
>
> But the difference in speed even on Wayland is negligible, not easy to
> benchmark, and not at all visible to the human eye.

Appreciate the efforts on this, but the outcome seems somewhat
unsatisfactory, if I understand correctly:

- we have the "non-pure" gtk build which supports X (although gtk has a
  wayland backend, non-pure gtk assumes X)
- we have "pure" gtk, which supports X and Wayland, but now it turns
  out there's a bunch of limitations on X.

>From the the time before pgtk got merged, I can't remember any wide
discussion of it being wayland-only. Perhaps I misremember.

I regularly use both X and Wayland, and having to have two emacsen (and
remember to use the right one) just for that seems sub-optimal. Wouldn't
it be better to have a single gtk3 backend? For users and developers and
distributors?

But maybe the problems is small, i.e. perhaps pgtk works fine on X, but
doesn't currently implement a handful of things, which we can document?
Then users can decide if they can live with that.

Kind regards,
Dirk.

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