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 02:33:14 +0000 [thread overview]
Message-ID: <87mtgga3h6.fsf@treypeacock.com> (raw)
In-Reply-To: <875yn4eg0w.fsf@yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 3921 bytes --]
"Po Lu" <luangruo@yahoo.com> writes:
> Trey Peacock <gpg@treypeacock.com> writes:
>
>> It does not seem to be a requirement of GTK 3.2 or XKB to send virtual
>> modifiers.
>
> 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.
>> The only compositor I have come across that actually sends a virtual
>> modifier is mutter/GNOME. Neither wlroots nor Weston, the Wayland
>> reference implementation, send them. I'm unsure about Plasma, but I
>> believe this highlights an issue with the development of pgtk, if it
>> is meant to be targeted towards wayland users it should be tested
>> against more than just one compositor.
>
> I don't have any other compositor installed that I can actually start.
> Users, such as you, are supposed to do that part of the job.
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.
>> The experience of a user updating Emacs and realizing a key is no longer
>> recognized, without any notification or justification would also be a
>> step backwards.
>
> That is the price you pay when using the development version of Emacs.
> The key wasn't intentionally disabled, so I cannot know those problems
> exist until users like you report them.
>
> Hopefully, those problems will no longer exist when Emacs 29.1 is
> released.
100% agree about the risks and responsibilities of users of dev
versions. That's why I wanted to bring this to attention.
>> I have spoken with devs of wlroots & wayland over IRC and they seem to
>> agree that it is not necessary. I don't mean to be adversarial but would
>> be happy to see this change amended to incorporate the entirety of
>> wayland compositors.
>
> Wayland compositors do not send those virtual modifier masks. GDK is
> supposed to, and does it correctly when running on GNOME Shell, so the
> bug either lies in GTK or the other Wayland compositors.
The reason this works is because mutter sends additional virtual
modifiers. You can see more here:
https://gitlab.gnome.org/GNOME/mutter/-/commit/0fa9751b3144aef5faaca1ad381b6f86b5f30994.
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.
Now, if we were building this against Gtk 4 then I would agree with you
it seems to be the direction it's going. Though still not fully
explicit.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/docs/reference/gtk/migrating-3to4.md#adapt-to-changes-in-keyboard-modifier-handling.
Your change seems to have removed a fallback in case there were no
virtual modifiers and reverses the previous logic:
previously: if a virtual modifier exists equal to GDK_SUPER_MASK then
super_mod_mask = GDK_MOD4_MASK, if it does not equal GDK_SUPER_MASK then
it just passes the state & current value. Lastly, if a virtual modifier
does not exist super_mod_mask=GDK_MOD4_MASK.
current: only if a virtual modifier exists does super_mod_mask =
GDK_SUPER_MASK.
x_find_modifier_meanings (struct pgtk_display_info *dpyinfo)
{...
- state = GDK_SUPER_MASK;
- r = gdk_keymap_map_virtual_modifiers (keymap, &state);
- if (r)
- {
- /* Super key exists. */
- if (state == GDK_SUPER_MASK)
- {
- dpyinfo->super_mod_mask = GDK_MOD4_MASK; /* maybe this is super. */
- }
- else
- {
- dpyinfo->super_mod_mask = state & ~GDK_SUPER_MASK;
- }
- }
- else
- {
- dpyinfo->super_mod_mask = GDK_MOD4_MASK;
- }
...
}
...
pgtk_gtk_to_emacs_modifiers (struct pgtk_display_info *dpyinfo, int state)
{...
- if (state & dpyinfo->super_mod_mask)
+ if (state & GDK_SUPER_MASK)
mod |= mod_super;
...
}
[-- 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 --]
next prev parent reply other threads:[~2022-04-20 2:33 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-18 21:50 PGTK-related misconceptions 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2022-04-20 7:52 Trey Peacock
2022-04-20 8:25 ` Po Lu
2022-04-20 13:13 ` Brian Cully
2022-04-15 2:01 bug#53200: 29.0.50; C-S-u shortcut fails with 'PGTK' enable Morgan Smith
2022-04-15 2:29 ` PGTK-related misconceptions 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mtgga3h6.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.