* Modifier handling in pgtk
@ 2021-12-11 23:25 Brennan Vincent
2021-12-12 1:15 ` Po Lu
0 siblings, 1 reply; 6+ messages in thread
From: Brennan Vincent @ 2021-12-11 23:25 UTC (permalink / raw)
To: emacs-devel
Hello,
It seems like pgtkterm.c is simply always assuming that mod4 corresponds
to the super key, mod3 to hyper, and so on. For example, in this code
from x_find_modifier_meanings :
state = GDK_HYPER_MASK;
r = gdk_keymap_map_virtual_modifiers (keymap, &state);
if (r)
{
/* Hyper key exists. */
if (state == GDK_HYPER_MASK)
{
dpyinfo->hyper_mod_mask = GDK_MOD3_MASK; /* maybe this is hyper. */
}
else
{
dpyinfo->hyper_mod_mask = state & ~GDK_HYPER_MASK;
}
}
else
{
dpyinfo->hyper_mod_mask = GDK_MOD3_MASK;
}
Later when we receive key events, we will check them against this
`hyper_mod_mask` and therefore think that any with mod3 set have the
hyper key set. The result is that things won't work right for people who
have used xmodmap to change which modifier flags hyper, super, etc. are
mapped to.
I'm confused about what's going on here -- why do we need to set up this
state in dpyinfo at all; why can't we just compare against
GDK_HYPER_MASK, GDK_SUPER_MASK, etc. directly in
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Modifier handling in pgtk
2021-12-11 23:25 Modifier handling in pgtk Brennan Vincent
@ 2021-12-12 1:15 ` Po Lu
2021-12-12 13:15 ` Yuuki Harano
0 siblings, 1 reply; 6+ messages in thread
From: Po Lu @ 2021-12-12 1:15 UTC (permalink / raw)
To: Brennan Vincent; +Cc: emacs-devel, Yuuki Harano
Brennan Vincent <brennan@umanwizard.com> writes:
> I'm confused about what's going on here -- why do we need to set up this
> state in dpyinfo at all; why can't we just compare against
> GDK_HYPER_MASK, GDK_SUPER_MASK, etc. directly in
This is probably a vestige of the X code most of the PGTK code was
derived from. I will remove it in favour of the more idomatic GDK
modifier masks performed by GTK in a while, if Yuuki has no objections.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Modifier handling in pgtk
2021-12-12 1:15 ` Po Lu
@ 2021-12-12 13:15 ` Yuuki Harano
2021-12-23 9:35 ` Jindřich Makovička
0 siblings, 1 reply; 6+ messages in thread
From: Yuuki Harano @ 2021-12-12 13:15 UTC (permalink / raw)
To: luangruo; +Cc: brennan, emacs-devel
On Sun, 12 Dec 2021 09:15:38 +0800,
Po Lu <luangruo@yahoo.com> wrote:
> This is probably a vestige of the X code most of the PGTK code was
> derived from. I will remove it in favour of the more idomatic GDK
> modifier masks performed by GTK in a while, if Yuuki has no objections.
OK. No objection.
--
Yuuki Harano
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Modifier handling in pgtk
2021-12-12 13:15 ` Yuuki Harano
@ 2021-12-23 9:35 ` Jindřich Makovička
2021-12-23 9:40 ` Po Lu
2021-12-23 14:42 ` Yuuki Harano
0 siblings, 2 replies; 6+ messages in thread
From: Jindřich Makovička @ 2021-12-23 9:35 UTC (permalink / raw)
To: Yuuki Harano; +Cc: luangruo, brennan, emacs-devel
On Sun, 12 Dec 2021 22:15:13 +0900 (JST)
Yuuki Harano <masm+emacs@masm11.me> wrote:
> On Sun, 12 Dec 2021 09:15:38 +0800,
> Po Lu <luangruo@yahoo.com> wrote:
> > This is probably a vestige of the X code most of the PGTK code was
> > derived from. I will remove it in favour of the more idomatic GDK
> > modifier masks performed by GTK in a while, if Yuuki has no
> > objections.
>
> OK. No objection.
I noticed one more thing related to the modifiers - pgtk emacs will not
recognize the keypad keys, because they are passed to GTK IM, and the
keypad information is dropped. So, emacs receives ordinary "1" instead
of "kp-1".
Regards,
--
Jindrich Makovicka
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Modifier handling in pgtk
2021-12-23 9:35 ` Jindřich Makovička
@ 2021-12-23 9:40 ` Po Lu
2021-12-23 14:42 ` Yuuki Harano
1 sibling, 0 replies; 6+ messages in thread
From: Po Lu @ 2021-12-23 9:40 UTC (permalink / raw)
To: Jindřich Makovička; +Cc: Yuuki Harano, brennan, emacs-devel
Jindřich Makovička <makovick@gmail.com> writes:
> I noticed one more thing related to the modifiers - pgtk emacs will
> not recognize the keypad keys, because they are passed to GTK IM, and
> the keypad information is dropped. So, emacs receives ordinary "1"
> instead of "kp-1".
That's the responsibility of your GTK input method; you can disable it
by calling a function, but I don't know its name. Perhaps Yuuki can
help here as well.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Modifier handling in pgtk
2021-12-23 9:35 ` Jindřich Makovička
2021-12-23 9:40 ` Po Lu
@ 2021-12-23 14:42 ` Yuuki Harano
1 sibling, 0 replies; 6+ messages in thread
From: Yuuki Harano @ 2021-12-23 14:42 UTC (permalink / raw)
To: makovick; +Cc: luangruo, brennan, emacs-devel
On Thu, 23 Dec 2021 10:35:13 +0100,
Jindřich Makovička <makovick@gmail.com> wrote:
> I noticed one more thing related to the modifiers - pgtk emacs will not
> recognize the keypad keys, because they are passed to GTK IM, and the
> keypad information is dropped. So, emacs receives ordinary "1" instead
> of "kp-1".
Thanks for the notice.
But I have no idea about how to solve it for now...
--
Yuuki Harano
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2021-12-23 14:42 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2021-12-11 23:25 Modifier handling in pgtk Brennan Vincent
2021-12-12 1:15 ` Po Lu
2021-12-12 13:15 ` Yuuki Harano
2021-12-23 9:35 ` Jindřich Makovička
2021-12-23 9:40 ` Po Lu
2021-12-23 14:42 ` Yuuki Harano
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).