emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PGTK-related misconceptions


From: Akira Kyle
Subject: Re: PGTK-related misconceptions
Date: Mon, 25 Jul 2022 15:18:31 -0600
User-agent: mu4e 1.6.11; emacs 29.0.50


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?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]