Bug 151811

Related report:
https://bugs.kde.org/show_bug.cgi?id=137079

Re comment #1, that report is not related to this one.  The problem with accelerator keys is a bug.

A few general comments on the suggestion:

1.  I want to keep the menus as trim as possible.  Adding a submenu along the lines of "Press Key -> Ctrl+C , Ctrl+V ..." which will contain menu items which are not relevant to many users goes against this ideal.

2.  A blanket solution would be to have a mode in which all key presses are sent to the terminal, regardless of whether they match a shortcut combination or not.  The problem with this is that users could easily make mistakes if they think the mode is enabled when it is not and vice versa.

ad.1) compare it to VirtualBox, the list is pretty short

Konsole could provide default list:
ctrl+c
ctrl+d
ctrl+alt+del

Take a look at VB. However additional, ONE entry, could be, keypress on the fly. Then the dialog would appear, user would press the key, and that key would be sent directly to konsole program.

Another approach would be to just allow the user to define his/her keys. Similar to bookmarks (Konq) -- from start there are 4 entries, but user can define tons of them. So here, user wants ctrl+v, fine, another user want ctrl+f, also fine, each user defines own keypress menu entries.

I do not understand the Ctrl+C exmpale. The original report suggests Ctrl+C would both trigger the copy action and be sent into terminal process. But that would only cause problem. Suppose:

    1). In the bash, I type "echo "
    2). I press Ctrl+C to paste something, or abort current line.
    3). something is pasted after "echo " by konsole, then the terminal proecess(bash in this case) receive the Ctrl+C so it aborts current line.
    4). or, the terminal process(bash) receives the Ctrl+C and aborts the current line, then something is pasted by konsole.

both results are broken. I guess what the reporter want is Ctrl+C can be intercepted as shortcut or sent into terminal process by konsole in a intelligent way, but not at the same time. However, my feeling is such inteliigence guessing would only be error prone.

The only feature I could find in the VirtualBox user manual that resembles this is documented in the two sections starting at http://www.virtualbox.org/manual/ch01.html#idp7665552

The implementation involves reserving a modifier key (aka the "Host Key") for the sole use of VirtualBox, and when pressed in combination with other configured keys you can send a keystroke that would normally be consumed by the host environment, or cause VirtualBox to capture the keyboard and direct all keystrokes to the VM. The default VirtualBox host key is the right ctrl key.

In Maciej's example, the ctrl-c combination would actually be entered with the Host Key and would not be confused with the real ctrl-c combination by Konsole.

In the case of an application like VirtualBox this is fairly straightforward, but I don't know how the konsolepart would handle this when used in conjunction with another app. In all likelihood the container app wouldn't be able to offer the dedicated modifier key, creating a difference in behavior that would be a source of confusion for those using both Konsole and the kpart.

@Jekyll,

  Depending of your wish it would be:
a) intercepting such keys as ctrl+c and menus like entries "send KDE ctrl+c action w/o intercepting it".

b) not intercepting such keys as ctrl+c and menus like "send raw console ctr+c"

It would be user preference if he prefers having KDE, consistent shortcuts, and send raw codes with menu (+ maybe some twisted shortcuts, like alt+ctrl+c to get ctrl+c), or rather use raw ctrl+c shortcuts as primary and use KDE actions from menu.