Shortcuts not properly ignored in various text fields.

[RazviOverflow]

Environment information

• Operating System: Kali 2024.02
• Cutter version:
  Version 2.3.4
  Using rizin 0.7.1 @ linux-x86-64 commit: 7cb15e769c9e8d83de041634dc8a35634ee1cbb7
  Based on Qt 5.15.5 (GCC 7.5.0, 64 bit)
  Optional Features:
  Python: ON
  Python Bindings: ON
• Obtained from:
  • Built from source
  • Downloaded release from Cutter website or GitHub
  • Distribution repository
• File format: Irrelevant

Describe the bug

When trying to filter functions based on their name (Quick Filter), some keystrokes are intercepted for their bindings instead of writing the actual letter. For example, try writing main. It will write mai and pop up the rename function dialog (Function rename is bound by default to N).

To Reproduce

Steps to reproduce the behavior:

1. Open any binary.
2. In the Functions window use the Quick Filter function (at the bottom) to search functions.
3. Write main to see the problem.

Expected behavior

The expected behavior is disabling the keyboard shortcuts while the cursor is within the Quick Filter box, allowing the user to write any given text.

[karliss]

Just like other similar bugs of shortcuts triggering when they should this seems to only affect the QT5 Appimage build. As a temporary workaround you can try the latest Qt6 dev build from here https://github.com/rizinorg/cutter/actions/runs/11443723247 .

But I have an idea how it might be possible to fix this for QT5 as well, at least in this specific case.

[karliss]

Known problematic shortcuts:

• 'F', 'X', ';' in functions widget filter (fixed in Fix function widget unintended shortcut activation. #3389)
• '.' in functions widget filter
• 's' 'g' in console or function search

[karliss]

Since this seems to for the most part affect only QT5 appimage build (I feel like it didn't happen with locally built QT5 builds but I am not fully sure) it's probably at least partially a qt5 bug. Would be good to do a qt5 cutter-deps rebuild using KDE bugfix branch. It will take some work updating build scripts since the KDE repos have slightly different structure and it will probably be necesarry to setup container based build.

With that in some of the cases like #3389 there are simple workarounds, and I wouldn't be surprised if some of the cases are really caused by cutter using QT incorrectly and wouldn't be fixed by Qt bugfix.

[karliss]

The qt5 rebuild might be less bad than I thought. KDE does have a qt meta repository with all the submodules, previously I thought it would be necessary to gather source from the dozen separate repos which would be a bit more work reworking builds scripts.