what is reason for this behavior?
I think there is some uncommon way how keyboard is processed — I have keyboard layout, which generated on win-e <arrowUp> symbol, not having to jump to arrow keys all the time. The problem is, that when I press win-e, konsole gets info about pressed key: UP, but for some reason, it probably checks on it's own state of modifiers to find out, that win key is down, and generates win-<up> instead, which for konsole generates symbol A. Please advise how to get rid of this.

Too sad, that there is so little activity here. BUT! If you are reading this and having issue with this, you have your lucky day.

settings-> manage profiles -> edit custom profile -> keyboard and change from XFree4 to linux console and you should be good.

No idea what that is. And there is one more issue I found out (no point of creating new subject).

Say you wanted to define your C symbol to produce escape on level 5, because why not:

key <AB03> { [ c, C, Escape, NoSymbol ] };

But if you do that, out of nowhere, combination ctrl-c does not work. WHY??? No idea. You asked for <win-key>-C to be escape and there is no collision with ctrl-escape. For some reason, there is observed conflict with ctrl-escape global shortcut for 'show system activity' app. Kill this shortcut and it's working again. There is definitely something flawed here, but at least there is workaround in disabling global shortcuts.

Hi!

I cannot answer your question but give you some hints. There are a lot of levels concerning key input and sequences. The kernel itself changes keyboard input on boot which makes/could make it behave different from the uefi-implementation. Then you have the tty setting, e.g. `loadkeys us` or using a GUI the X/Wayland layout using localectl, setxkbmap, etc. This is configurable using custom layouts in /usr/share/X11/xkb or helpers like xmodmap.
On top of this there is the Qt-Keyhandling which for exampe lacks of support for the Hyper-Key (normally not used, see Spacecadet Keyboard for an old layout ) but respects the modifications of xkb. And then finally the Plasma-Shortcut-Handler based on the Qt-stuff which parses every keyboard input for known shortcuts. On top of this, every application can handle its key input different. If the global Plasma handler does not find a shortcut, it forwards the key input to the application having focus, so you can e.g. enter an url in your browser or write this text

If you now hit a key combination, e.g. ctrl-esc, kglobalaccel(?) looks up this combination and finds it, running the task manager. If you disable this shortcut, it does not find the combination and the focused app gets the signal ctrl-esc which it can handle (or not).

sure, I do realize that I knew most of that. But. The puzzling part is this: At beginning it works. Then I define that level5-c is escape, and level 5 in my case is mapped on win key. So win-c is escape. If I do that ctrl-c stops working. If I then unbind ctrl-escape global shortcut, it works again. It does not make any sense, I cannot explain where the conflict can be, as I did NOT press ctrl escape, I press ctrl-c and it get swallowed. Really I cannot imagine KDE logic, which isn't totally pointless and which could lead to this situation.

I cannot either. The default on pressing ctrl-c is sending a SIGINT (program termination) to the current running process.

As you mentioned lvl5: I do use a eight level keyboard layout myself and sometimes there is a strange behaviour which works like a level5lock, so perhaps you do not send ctrl-c but the level 5 version which is not defined in your layout. Can you try to bind e.g. CapsLock to level5 and try again (I'm using NumLock on a full keyboard with num pad as level5switch)?
Perhaps it helps if you check the recognized key signals using `xev` on XServer or `wev` on Wayland and additionally check the recognized levels with `xmodmap` where the level key definitions are visible.

Depending on how your keyboard is build up (the hardware itself) you cannot use every key in every combination. But the two changes you mentioned should work on any keyboard. At least I do not now any that separated the escape-key from the often separated modifier keys in the column/row-layout.

well no.
Sure ctrl-c is sigint. But this layout is tested for 5+ years in multiple distros and wms. It's not problem of layout. And again, I'm pressing ctrl-c. No matter of lvl5/lvl8, my ctrl is still ctrl, so this is ctrl-c. But assume it's not, and layout is sending something else for whichever reason. How could that change by removing global kde shortcut? It cannot. Contradiction. So it's really not that. And xev really shows, that ctrl-c is ctrl-c.

Well it's some kde mystery then, but at least we do know the solution. Last time I ditchech kde for cinnamon for this After years I forgot, install all work related stuff only to find out this again, but luckily I was able to figure out workaround this time. I hope there arent more of them.

Well, as mentioned in my first post, there are some issues in Qt like not handling a Hyper key which broke my custom layout using this key. But I cannot reproduce a wrong behaviour on ctrl-c. In your example you are changing the third level to Esc not the fifth, but I think that was just an explanation?