unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Trey Peacock <gpg@treypeacock.com>
To: Po Lu <luangruo@yahoo.com>
Cc: Morgan Smith <morgan.j.smith@outlook.com>, emacs-devel@gnu.org
Subject: Re: PGTK-related misconceptions
Date: Wed, 20 Apr 2022 07:52:56 +0000	[thread overview]
Message-ID: <87bkww9ooc.fsf@treypeacock.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 3202 bytes --]

"Po Lu" <luangruo@yahoo.com> writes:

> Trey Peacock <gpg@treypeacock.com> writes:
>
>>> See https://docs.gtk.org/gdk3/flags.ModifierType.html, which says:
>>>
>>>   Since 2.10, GDK recognizes which of the Meta, Super or Hyper keys are
>>>   mapped to Mod2 - Mod5, and indicates this by setting GDK_SUPER_MASK,
>>>   GDK_HYPER_MASK or GDK_META_MASK in the state field of key events.
>>
>> The capability to do something is not the same as a requirement.
>
> It's the documented behavior of GDK, and Emacs holds GDK to its
> documentation.  Nowhere does the documentation say this is a
> "capability", "recognizes" is in the third-person present tense, which
> makes it a requirement.
>
>> I would be happy to help. Granted, this is only my second interaction on
>> the mailing list, but I do want to contribute how I can.
>
> Great, one step forward would be to bring up the issue with either the
> GTK or Wayland compositor developers.  Since you've already talked with
> the latter, and they say it's not their problem, please contact the
> former.
>
>> It is not GDK that is responsible for this. Further, since this is not
>> required, I don't think its proper to deem it a bug.
>
> It is, as specified in its documentation.
>
>> Your change seems to have removed a fallback in case there were no
>> virtual modifiers and reverses the previous logic:
>
> As you can see by the name of the function, it was directly ported over
> from X (the current version is in xterm.c), and is yet another example
> of the PGTK port translating X Windows code to GDK verbatim, duplicating
> what GDK is supposed to do itself.
>
> I will not change Emacs because the GTK developers, yet again, forgot to
> follow their own documentation when implementing some feature.  It just
> makes Emacs code bloated, hard-to-follow and liable to break at the
> slightest whim of the GTK developers, who then respond that we're not
> using GTK "properly", because we try to work around their problems.

You have already changed Emacs from accepting both MOD4 and SUPER_MASK
as its Super key modifiers to only accepting SUPER_MASK. I imagine this
response is born of more than just this issue but I would not let it
cloud an easy solution.

GTK 3.24.33 still accepts Mod2-5 masks, recognizes them separately from
the virtual modifier masks, and unlike the x11 implementation does not
contain the logic to set convert Super_L or Super_R to GDK_SUPER_MASK.
So what you have done is actually held Emacs to GDK's x11
implementation and documentation rather than looking at the code itself.

https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/wayland/gdkkeys-wayland.c#L249-316
https://gitlab.gnome.org/GNOME/gtk/-/blob/3.24.33/gdk/x11/gdkkeys-x11.c#L396-398

If the PGTK branch is meant for "alternative window systems available on
GNU/Linux and some Unix systems, such as Wayland" then I do think there
should be more consideration taken compositors that do not share
Mutter's workaround. Had you been using any other compositor, surely you
would not have made this change. Perhaps even filing a bug yourself.

This will be my last comment on the matter as I don't think its
productive for either of us to belabor our points.

[-- Attachment #1.2: publickey - gpg@treypeacock.com - da008078.asc --]
[-- Type: application/pgp-keys, Size: 1339 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 249 bytes --]

             reply	other threads:[~2022-04-20  7:52 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-20  7:52 Trey Peacock [this message]
2022-04-20  8:25 ` PGTK-related misconceptions Po Lu
2022-04-20 13:13   ` Brian Cully
  -- strict thread matches above, loose matches on Subject: below --
2022-04-18 21:50 Trey
2022-04-19  0:59 ` Po Lu
2022-04-19  3:28   ` Trey Peacock
2022-04-19  4:27     ` Po Lu
2022-04-19 23:02       ` Trey Peacock
2022-04-20  0:48         ` Po Lu
2022-04-20  2:33           ` Trey Peacock
2022-04-20  4:05             ` Po Lu
2022-07-25 21:18     ` Akira Kyle
2022-07-26  2:08       ` Po Lu
2022-07-26 12:10         ` Lars Ingebrigtsen
2022-07-26 12:35           ` Po Lu
2022-07-29 14:26             ` Stefan Monnier
2022-07-30  0:58               ` Po Lu
2022-07-26 21:36         ` Akira Kyle
2022-07-27  2:48           ` Po Lu
2022-07-27  8:34             ` Trey Peacock
2022-07-27  9:10               ` Po Lu
2022-07-27 13:45                 ` Trey Peacock
2022-07-27 13:52                   ` Po Lu
2022-07-28  1:39             ` Akira Kyle
2022-07-28  2:50               ` Po Lu
     [not found] <DM5PR03MB3163BBCF9626AD3B88900011C5EE9@DM5PR03MB3163.namprd03.prod.outlook.com>
2022-04-15  2:29 ` Po Lu
2022-04-15  7:11   ` Byung-Hee HWANG
2022-04-15 16:24   ` Eric Abrahamsen
2022-04-18  5:18   ` Sean Whitton
2022-04-18  5:31     ` Po Lu
2022-04-18  5:43       ` Sean Whitton
2022-04-18  5:57         ` Po Lu
2022-04-18 18:27           ` Sean Whitton
2022-04-18 19:49           ` Jim Porter
2022-04-19  1:02             ` Po Lu
2022-04-19  2:46               ` Sean Whitton
2022-04-19  2:18             ` Tim Cross
2022-04-19  5:56               ` Eli Zaretskii
2022-04-19  8:13                 ` Tim Cross
2022-04-19 10:32                   ` Eli Zaretskii
2022-04-19  9:10   ` Dirk-Jan C. Binnema
2022-04-19 10:42     ` Po Lu
2022-04-19 11:53     ` Phil Sainty
2022-04-19 13:58       ` Sean Whitton
2022-04-20  3:29         ` Phil Sainty
2022-04-20  4:48           ` Stefan Monnier
2022-04-19 16:51       ` Yuri Khan
2022-04-22  5:44         ` Pankaj Jangid

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87bkww9ooc.fsf@treypeacock.com \
    --to=gpg@treypeacock.com \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    --cc=morgan.j.smith@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).