Re: PGTK-related misconceptions

[Akira Kyle <akira@akirakyle.com>]

On Tue, Apr 19, 2022 at 03:28 AM, Trey Peacock 
<gpg@treypeacock.com> wrote:

> Neither of the WMs I mentioned use GNOME Shell, but they do both 
> use
> wlroots. Looking into this, it seems that any wlroots based 
> Wayland
> compositor will use GDK_MOD4_MASK as Super. However, mutter 
> (GNOME's WM)
> uses GDK_SUPER_MASK. Rebuilding emacs with the below patch seems 
> to have
> fixed the issue. I'm not sure if there could be further 
> implications for
> pgtk_emacs_to_gtk_modifiers.
>
>
> diff --git a/src/pgtkterm.c b/src/pgtkterm.c
> index 2b04699fb3..d8ca89bbc0 100644
> --- a/src/pgtkterm.c
> +++ b/src/pgtkterm.c
> @@ -5152,7 +5152,7 @@ pgtk_gtk_to_emacs_modifiers (struct 
> pgtk_display_info *dpyinfo, int state)
>      mod |= mod_ctrl;
>    if (state & GDK_META_MASK || state & GDK_MOD1_MASK)
>      mod |= mod_meta;
> -  if (state & GDK_SUPER_MASK)
> +  if (state & GDK_SUPER_MASK || state & GDK_MOD4_MASK)
>      mod |= mod_super;
>    if (state & GDK_HYPER_MASK)
>      mod |= mod_hyper;
> @@ -5285,7 +5285,7 @@ key_press_event (GtkWidget *widget, 
> GdkEvent *event, gpointer *user_data)
>        /* While super is pressed, the input method will always 
>        always
>      resend the key events ignoring super.  As a workaround, 
>      don't
>      filter key events with super or hyper pressed.  */
> -      if (!(event->key.state & (GDK_SUPER_MASK | 
> GDK_HYPER_MASK)))
> +      if (!(event->key.state & (GDK_SUPER_MASK | GDK_HYPER_MASK 
> | GDK_MOD4_MASK)))
>     {
>       if (pgtk_im_filter_keypress (f, &event->key))
>         return TRUE;


Thank you for this patch! I recently updated and ran into this 
issue. From the discussion in this thread, I really don't 
understand why this change was made. Is this fixing some issue for 
some other non-wlroots based compositor?

If it isn't, but was just made "to comply with the GDK docs" this 
would seem to be just be making life more difficult for those of 
use on wlroots based compositors. Emacs has many other places 
where it tries to work around quirks and other issues with GTK for 
the benefit of the user, so why would this be any different?