Home/ Questions/Q 7500327
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-29T20:08:33+00:00

I’ve got a simple Tkinter application I’ve written, with a few buttons at the

  • 0

I’ve got a simple Tkinter application I’ve written, with a few buttons at the bottom of a form. My goal is to follow the standard convention of underlining a letter on the button, and binding an action for that letter with the Alt key (ie: Alt-s for “_S_ave”).

I’ve tried making a root window binding to “Alt-s”, “Alt-KeyPress-s”, and “Mod1-s”, and none seem to work reliably. They sometimes fire, but even though I have “return break” on my event function the “s” letter is propagating to the entry widget.

I believe this is an issue with Linux/X11 and Mod1 vs Alt handling because Control key bindings work consistently. I haven’t been able to locate any best practices for working around the issue, thus my appeal here.

Can someone share how to get an Alt key binding working in Linux/X11?

** Updated with a sample

from Tkinter import *

class GUI:
    def __init__(self,root):
        self.root = root
        e = Entry(self.root)
        e.grid(column=0,row=0)
        b = Button(self.root, text="Save", underline = 0)
        b.grid(column=0,row=1)
        root.bind("<Alt-s>",self.save)
        e.focus()

    def save(self,event=None):
        print("Hey, you pressed Alt-s!")
        return "break"

root = Tk()
App = GUI(root)
print("At this point, pressing Alt-s places the s string in the entry widget, and doesn't trigger")
root.mainloop()

** Update 2

I’ve had a few reviewers let me know this works on their system, even Linux. Perhaps there’s a problem with my tiling wm or other configuration for X11, however I’ve had no problems using Alt with any other X11 GUI apps.

I’m open to suggestions on how to troubleshoot this.

** Update 3

I’ve been reviewing the behavior with xmodmap, and it appears that when I assign Alt_R the Tk keybindings stop working. The events reported by xev match verbatim, and yet Tk’s behavior changes. Still digging.

** Update 4

Mr. Lange on the Tkinter list found a link that helps explain similar behavior, at https://bbs.archlinux.org/viewtopic.php?id=58145 .

I’ve made that change to my xmodmap, and now Alt works as expected. I can’t explain why binding Alt_R to mod4 would effect Alt_L, or why it would only effect Tk applications.

Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The answer is that modifying Alt_R to bind it to the Windows key (Mod4) was the root cause of the problem. I believe that made Alt_L work as Mod1 though it was explicitly not modified in xmodmap. Therefor it must have broken some implied behavior, but only for Tk apps.

    From the Arch BBS link modifying the Alt_R keycode to trigger Super_L resolved the behavior. So now Alt_R functions as the Windows key, but Tk doesn’t notice any changes with Alt_L.

    Root bindings for Alt now work appropriately without double binding, because Entry widgets ignore Alt keypresses by default. With proper Alt behavior, not only are the Alt key bindings working, but the return break behavior isn’t required either.

    I did not see default ignore bindings for Mod1 keys in any widget, and if Alt_L suddenly decided to present Mod1 that does explain the behavior where Mod1 bindings would fire, but a double binding was required to prevent the Entry widget from getting the key.

    ~/.Xmodmap for reference:

    ! ISO_Level3_Shift is what xev reports for my right Alt key
! mod4 is the Windows key modifier, and tied to WM operations

! Trying a different approach documented at
! https://bbs.archlinux.org/viewtopic.php?id=58145
keycode 108 = Super_L
remove mod1 = Super_L

    What a messy problem, altering an undocumented implied behavior through an indirect change…

    • 0