[Bug] `grab_anywhere_using_control` feature is interfering with control+arrow keys

[kurtrowley]

Type of Issue (Enhancement, Error, Bug, Question)

Bug

---

Environment

Operating System

Linux version ('glibc', '2.35')

PySimpleGUI Port (tkinter, Qt, Wx, Web)

tkinter

---

Versions

Python version (sg.sys.version)

3.10.6 (main, Mar 10 2023, 10:55:28) [GCC 11.3.0]

PySimpleGUI Version (sg.__version__)

4.61.0.163

GUI Version (tkinter (sg.tclversion_detailed), PySide2, WxPython, Remi)

8.6.12

---

Your Experience In Months or Years (optional)

Years Python programming experience Years Programming experience overall No Have used another Python GUI Framework? (tkinter, Qt, etc) (yes/no is fine)

---

Troubleshooting

These items may solve your problem. Please check those you've done by changing - [ ] to - [X]

• [X] Searched main docs for your problem www.PySimpleGUI.org
• [X] Looked for Demo Programs that are similar to your goal. It is recommend you use the Demo Browser! Demos.PySimpleGUI.org
• [ ] If not tkinter - looked for Demo Programs for specific port
• [ ] For non tkinter - Looked at readme for your specific port if not PySimpleGUI (Qt, WX, Remi)
• [ ] Run your program outside of your debugger (from a command line)
• [ ] Searched through Issues (open and closed) to see if already reported Issues.PySimpleGUI.org
• [ ] Upgraded to the latest official release of PySimpleGUI on PyPI
• [ ] Tried using the PySimpleGUI.py file on GitHub. Your problem may have already been fixed but not released

Detailed Description

The (grab_anywhere_using_control=) feature in the window object is causing contro+arrow keys to grab and move the window down. No matter which arrow key is pressed while holding down control, the wondow moves down an increment for every contro+arrow keypress. Turning the feature off with (grab_anywhere_using_control=False),stops the problem and the control+arrow keys resume their normal text editing navigation functions (next/prior word, next/prior paragraph).

A work-around is to turn the feature off and use the Alt+mouse click to grab and move the window (which works fine). But I assume this is a bug since normally people would want to preserve normal editing functions even if the control+mouse click is used to grab and move (duplicating with alt+mouse click). Even the demo program has this problem.

Code To Duplicate

# Paste your code here
# ANY code illustrates this bug. Just run anything and try the control+arrow keys. 

Screenshot, Sketch, or Drawing

[PySimpleGUI]

No matter which arrow key is pressed while holding down control, the wondow moves down an increment for every contro+arrow keypress

For me (on Windows), the window moves in the direction of the arrow. Fine positioning of the window is why this feature was added. Sounds like maybe there's a Linux compatibility problem that I need to check out. As you said in the description you can turn off this feature. I'll see what's up with Linux. Thanks for logging an issue.

[PySimpleGUI]

Can you tell me which distribution of Linux you're running?

Also, please try using the latest PySimpleGUI on GitHub. There was a change in this area, but I don't see it in the changelog so don't know if you're running with that change.

I was able to duplicate a problem running Ubuntu. It does run correctly on Trinket when using the latest version on GitHub so it's not a problem that's on all Linux versions.

On the Ubuntu test, I saw that it's moving downward in addition to the direction of the arrow key. The jumps down were more than 1 pixel. Once the window reached the bottom of the screen, it stayed there and I was able to see that left and right moved by 1 pixel.

The amount it's moving downward by is suspiciously close to the size of the titlebar so there may be something about the location tkinter is reporting.

[kurtrowley]

I'm using the current PSG. Linux is Ubuntu 22.04.2 LTS. Yea I noticed the same thing. This is like a secondary added event processor, the intended screen movement works, but the down shifting is larger. BTW, I think the point that grab_anywhere_using_control overrides the customary control+arrow navigation in text entry elements should be in the documentation. It would be nice to have a third Non-Input mode for that also (True/False/Non-Input), where it is True for all non-input elements and window area, but turned off inside any text input element (Input/Multiline/Combo). This would allow the user to use the regular Ctl+Arrow navigation when editing text (next/prior word, etc). Alternatively you could add the ability to turn it off in input elements. But a global true for non-input switch would be easier. Right now I just have to turn it off globally and rely on Alt+Arrows to reposition the window.