Thank you for the pointer!
I had completely forgotten about that possibility. I used it in my first prototypes - long time ago :/
... in this case it did not help to get the desired result. Too many widgets between notebook and lineedit.
But it was very helpful any way!
It bothered me that even with Ctrl or Alt modifiers the number-/letter-keys produce an input in the lineedit.
With the event filter I was able to iron out the flawed concept.
First I did not like that I now have to code the access keys of the notebook in the editor. But after a short thought I realized that actually every input field needs an EventFilter to not process number and letter keys with modifiers as input.
This kind of workaround is ok for me now ;)
It works like this:
editor adds itself as eventfilter to lineedit
editor checks for modifiers at keypress
if a modifier is active, editor calls keyPressEvent followed by return true - without modifiers active eventFilter returns false, which leads to default key processing of lineedit. Those keys don't arrive at keyPressEvent.
keyPressEvent routes keys that will not be processed to its superclass. This will route key events to QMainWindow (I checked that by following timecode of event).
As its not possible to route events to widgets parents, it was possible to distribute events top down, as all classes are my classes.
So I changed keyPressEvent to public.
After that change, QMainWindow passes unprocessed key events to center widget (which in my case is a stacked layout). As I manage all stacked pages with an individual class, it was easy to change keyPressEvent to public too.
The stacked widget manager then distributes key events to the active page (widget), which in this case is the notebook.
It's a big detour until the event reaches its destination, but it works.
