@LeLev Thank you very much for your answer. It helped me to understand my issue a little more. So I tried your code, and it works, meaning that the ListView isn't eating the Space key.
However my interface is a little more complex than this one, it contains other objects like SwipeView, and yes, my items contain components like buttons which may take the focus. However I already tried to deactivate them and even thus the issue remained.
I played a while around the code you posted. I noticed that the following code no longer receives any key:
So I assume that some components operate like filters and may stop internally the keyboard signals, or at least a part of them, without let the choice to the developer to bypass this behavior (or at least I don't know how to do). To be honest I'm a little puzzled, because I worked for15 years with the Windows API before changing for Qt, and receiving a keyboard notification was never an issue, even when the parent component already received it before (in fact it was the contrary: the message could be blocked in the parent, but by default it was passing).
So now the question is: in the above code, how can I receive the keyboard signals, and in particular the Space key, in my ListView despite of the parent SwipeView? Or which solution is normally used in a such situation, e.g is there a way to globally listen the keyboard and intercept keys in the Windows level, BEFORE any component receives them?
I'm keeping this as unanswered until there is a workaround or a fix, but if you do not need dead keys or composition, just setting the XKB_DEFAULT vars and ensuring you are using libinput/xkbcommon should be enough to get your keyboard layout "working".
@raven-worx If I remove the line, the keyboard will never hide and the reason for adding visible: Qt.inputMethod.visible is because of the following line that I found in an example :
/* The visibility of the InputPanel can be bound to the Qt.inputMethod.visible property, but then the handwriting input panel and the keyboard input panel can be visible at the same time. Here the visibility is bound to InputPanel.active property instead, which allows the handwriting panel to control the visibility when necessary. */
Bad luck is that it's nowhere mentioned in any docs.