I will put this on my TODO list.

Thanks for considering this. I just wanted to remark that krdc 3.5.9 can do that, in case it helps.

Can you please test with the KDE 4.1 version of KRDC. This behavior has been changed (improved).

I can confirm that the bug with the arrow keys is still there in 4.1.1, but it seems to be fixed in trunk. I don't know about 4.1.2 and 4.2.

Another key combination that I can't get to work is Ctrl+Z. I can't see any reason why Ctrl+Z shouldn't be sent to the remote side. This is not fixed in trunk, and "grab all keys" doesn't help either.

I do not understand why there are differences between trunk and 4.1 stable branch. I think there are no changes in that part.

Anyway, I can reproduce the issue with CTRL-Z too.

Maybe the difference is caused by a change at a lower level, like kdelibs or Qt, e.g. the generic scroll viewer.

Note: we need to use "bool QWidget::x11Event(XEvent * event)" in VncView. Otherwise we miss some keyboard inputs.

*** Bug 187502 has been marked as a duplicate of this bug. ***

*** Bug 200778 has been marked as a duplicate of this bug. ***

Using version 4.3.1 I find that F1 is not trapped even when "Grab all possible keys" is checked - it brings up the local help window instead.

the "Grab all possible keys" option doesn't seem to have any effect whatsoever when connecting to a windows desktop. key combinations such as alt-tab, ctrl-esc and alt-f4 go to the local machine only. only combinations that are not used by KDE, such as alt-f5 are seen by windows. this is on KDE 4.3.1 that comes with openSUSE 11.2.

Confirm comment #11
I'm trying to use qemu remotely, but there's no way to send Ctrl-Alt-2 :(

Any progress on this issue? It's been open for almost 2 years, and makes it impossible to work with many remote applications from Linux via remote desktop.

actually there's a workaround for this problem. kwin supports per window rules that control many aspects of the window's behavior. one of them is disabling the global shortcuts when the window is active. this can be found in the control panel. i have defined a rule that matches the krdc windows and can use alt-tab and the other shortcuts in the windows session.

i suppose that one way for fixing this bug would be to programatically create such a rule when the "Grab all possible keys" option is activated.

Todor - thanks for this tip!

Any idea, fellow KWin developers?

Is there a way to tell an application programatically to grab all keys?

For more informations, see the full bugreport. Thanks a lot! This bug is very annoying for many people.

I think this bugreport is mixing two unrelated issues. What this started with looks like a problem with internal event dispatching, things like krdc sending arrow keys to both the remote machine and interpreting them locally need to be fixed in krdc (filtering them out from normal Qt processing, whatever).

Making krdc also capture global shortcuts is only possible by grabbing the whole keyboard (QWidget::grabKeyboard()), similarly to how e.g. VirtualBox does it.

Lubos, thanks for your comment. We do already call QWidget#grabKeyboard in the VNC widget. Do we need to call that from application level, i.e. KMainWindow? Does #grabKeyboard really catch *all* keys?

I don't know all details about QWidget::grabKeyboard(), all I can tell is that the widget should be visible by the time of the call. Doesn't it report problems if there is a failure. And yes, it should grab virtually all keys, except possibly ones like Ctrl+Alt+F1, you can make a small testapp to check this.

*** Bug 231771 has been marked as a duplicate of this bug. ***

The most annoying is that I cannot use any Alt+key, Ctrl+key combinations while connected to remote Windows session. For example, Alt+Tab switches to next KDE application. Alt+F2 shows a KDE window, etc.

Note: KRDC from KDE3 works perfectly fine.

I have just tried the described issues again. I cannot reproduce most of them anymore with KDE SVN trunk (which will be KDE SC 4.5). Please try to reproduce your issues as soon as you can. Thanks.

*** Bug 243730 has been marked as a duplicate of this bug. ***

I'm not using the sc from the trunk, but the binaries from Suse OBS. Current version of KDE is 4.4.4. Grab keys has no effect on Atl+F1 and Alt+F2. If it is no longer reproducible it would be quite good idea to backport changes to the KDE release currently used by current distos such as SuSE, for example. I can arrange a webex to troubleshoot the problem.

Vadim mentioned that I can try to use workarounds for the krdc window (i.e. block global shortcuts), however that didn't work.

Note: krdc from KDE 3.5 works fine with tricks. I need to minimize krdc window and maximize it back. After that Alt+F1, Alt+F2 works fine.

I too am using krdc from OpenSuse, it's still 4.4.4. The issue for me is mainly about alt-tab. I've no found that, while it fails in full-screen mode, it works in normal-window mode. This is a shame -- it forces me to hide the menubar in order to enjoy a full resolution -- but it is a workaround for me.

reg. all the shortcut issues in the last comments:
simply setup a rule for krdc to ignore global shortcuts
(call "kcmshell4 kwinrules" / "workarounds" tab)

As however Lubos pointed in comment #19, this seems completely unrelated to the original bug report.

*** Bug 258546 has been marked as a duplicate of this bug. ***

Even if "Grab all possible keys" is activated, the keys go to krdc after the window has lost focus.

To reproduce:
1. activate "Grab all possible keys"
2. pressed key (Ctrl-w) goes to the remote machine
3. activate another window
4. pressed key (Ctrl-w) goes to krdc, closing the connection

no idea whether the behavior makes sense, but "grab" actually does precisely this:
the grabbing client receives _all_ input events of the grabbed device, regardless of whether it has the kdb focus or not.

The only thing I cannot quite understand. This issue is around since KDE 4.0
has been introduced. It is just not working ever sinse. And, probably this
functionality is the most important when you want to have Linux running on
your system instead of Windows.

The only normal working remote desktop client in KDE is one from KDE 3.5.

- Alex.

On Wed, Feb 2, 2011 at 7:14 AM, Thomas Lübking <thomas.luebking@gmail.com>wrote:

> https://bugs.kde.org/show_bug.cgi?id=162723
>
>
>
>
>
> --- Comment #29 from Thomas Lübking <thomas luebking gmail com>  2011-02-02
> 16:14:16 ---
> no idea whether the behavior makes sense, but "grab" actually does
> precisely
> this:
> the grabbing client receives _all_ input events of the grabbed device,
> regardless of whether it has the kdb focus or not.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are a voter for the bug.
> You are on the CC list for the bug.
>

I've no idea about krdc, but for SheepShaver I simply set to ignore global shortcuts (for it does not grab the keyboard -and should no anyway, grabbing is evil- and you _need_ the alt key as it's the mac cmd key)

This is however _not_ related to the original bug which is just a matter of internal event dispatching. And comment #28 seems unrelated and rather a follow up to the bug introduced in #11 (now apparently expecting the opposite behavior)

However: setting the window rule instead of having krdc grabbing the keyboard will suppress global shortcuts while krdc is active and immediately "reactivate" them when another window (or none) gets the focus

I can confirm that this bug is fixed in at least KRDC 4.4.5. It *does* continue to grab keys, even after losing focus, but that is IMO a matter of personal preference, or at best a different bug. This bug is about grabbing keys, which now works. It should be closed as fixed.

This issue is still not fixed in 4.4.5. Hitting ctrl+w with "Grab keys" on still closes the session. In addition it sends the keydown event for ctrl to the server which means the Xserver running at the target machine thinks ctrl is pressed even after reconnecting.

Another keyboard issue is KRDC can't send the ctrl+shift+tab combo; I don't know whether this is related or not.

Best suggestion is to use KRDC from Kde 3.5. Everything works there.

- Alex
On Mar 7, 2011 3:00 AM, "Michal Petrucha" <johnny64@users.sourceforge.net>
wrote:
> https://bugs.kde.org/show_bug.cgi?id=162723
>
>
> Michal Petrucha <johnny64@users.sourceforge.net> changed:
>
> What |Removed |Added
>
----------------------------------------------------------------------------
> CC| |johnny64@users.sourceforge.
> | |net
>
>
>
>
> --- Comment #33 from Michal Petrucha <johnny64 users sourceforge net>
2011-03-07 12:01:45 ---
> This issue is still not fixed in 4.4.5. Hitting ctrl+w with "Grab keys" on
> still closes the session. In addition it sends the keydown event for ctrl
to
> the server which means the Xserver running at the target machine thinks
ctrl is
> pressed even after reconnecting.
>
> Another keyboard issue is KRDC can't send the ctrl+shift+tab combo; I
don't
> know whether this is related or not.
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are a voter for the bug.
> You are on the CC list for the bug.

Still not fixed in 4.6.4

I have the same problem: If I enable "grab all possible keys" and hit CTRL-W the session closes.
I had to disable the CTRL-W key shortcut in KRDC because I constantly hit this bug.
I think that if one enables "grab all possible keys" the shortcuts should be (temporarily) disabled.

*** Bug 270369 has been marked as a duplicate of this bug. ***

(In reply to comment #31)
> I've no idea about krdc, but for SheepShaver I simply set to ignore global
> shortcuts (for it does not grab the keyboard -and should no anyway, grabbing is
> evil- and you _need_ the alt key as it's the mac cmd key)
> 
> This is however _not_ related to the original bug which is just a matter of
> internal event dispatching. And comment #28 seems unrelated and rather a follow
> up to the bug introduced in #11 (now apparently expecting the opposite
> behavior)
> 
> However: setting the window rule instead of having krdc grabbing the keyboard
> will suppress global shortcuts while krdc is active and immediately
> "reactivate" them when another window (or none) gets the focus

Thomas: Can you enable / disable global shortcuts with some API?

YesNo.

The global approach actually *is* to grab the keyboard on focus in and release it on focus out - everything beyond is "proprietary" tricks of the WM and the globalaccel daemon. You however have to use this with two or three extra grains of salt.

If you do only care about a KDE environment (kwin/kgloablaccel), you can invoke a kwin shortcut (yes, there's a shortcut to toggle global shortcuts ;-) via the kglobalaccel dbus interface:

qdbus org.kde.kglobalaccel /component/kwin invokeShortcut 'Block Global Shortcuts'

The "pitfall" here's obviously that it toggles - and you can't query the current state.

The far better approach (for a KDE environment only again) would be to automatically inject a kwin rule for krdc with a kconfupdate (or similar) - there's such confupdate for xv windows which can likely be adapted.

Also the kcm even has im/export functions but they're not exported to CLI (since i didn't find the time to figure how to make a kcm interpret  kcmshell4 commandline args - yet. But this is actually on my todo. Could push it a bit ;-)

Thank you Thomas for the answer.

This fixes for example Ctrl-Alt-Delete, but still not for example Shift-F1 (Whats-This-Help); it still calls the action inside KRDC (even when keyboard grabbing is enabled). Do you have any idea how to disable that?

And about disabling global shortcuts: I still do not see the perfect solution here. When you disable global shortcuts per window rule, all global shortcuts will never work when KRDC has focus, even when there is no session open, right? Calling the dbus method is also no solution since the user might have disabled it already and we cannot check the status (as you have told already). So I'm really not sure, but probably disabling all global shortcuts in KRDC might be the "best" solution...

(In reply to comment #40)
> This fixes for example Ctrl-Alt-Delete, but still not for example Shift-F1
That's a local shortcut, entirely handled by the process internal Qt event dispatcher, ie. you can and must catch this locally.
Unfortunately, i'm not aware of a simple function to do this. Since it would require to collect all available shortcuts and dis/enable them, i guess the most straightforward approach would be to install an eventfilter and eat them/pass them to your client.

> And about disabling global shortcuts: I still do not see the perfect solution
> here. When you disable global shortcuts per window rule, all global shortcuts
> will never work when KRDC has focus, even when there is no session open, right?
Correct, static per/window rule - you however likely can change attributes like the window role or similar, so that the rule will only match when you want it.
I'm frankly not sure whether kwin catches those changes, but that could be considered a bug ;-)
On the other hand, this might be a good addition to the NETWM spec and before as proprietary _KDE_NETWM_BLOCK_GLOBAL_SHORTCUTS property.
Since kdelibs is frozen, you'd however have to #include <X11/Xlib.h> and XChangeProperty(.) "by hand" for this.

> Calling the dbus method is also no solution since the user might have disabled
> it already and we cannot check the status (as you have told already).
No and personally i don't like the fact that this shortcut is exported via dbus anyway (since it does unlike the kbd not require a direct user interaction) - for similar reasons i'd (personally) object adding a "legal" dbus interface for this to kwin.

(In reply to comment #41)
> On the other hand, this might be a good addition to the NETWM spec and before
> as proprietary _KDE_NETWM_BLOCK_GLOBAL_SHORTCUTS property.
> Since kdelibs is frozen, you'd however have to #include <X11/Xlib.h> and
> XChangeProperty(.) "by hand" for this.

I think that sounds like the best solution here. Do you have any hints how i could proceed here? I do not have much knowledge in that area.

Such support would have to be added to kwin first (ie. Martin has to agree that it makes sense and is a reasonable addition)
Afterwards it's just few X11 lines in your code:

static Atom blockGlobalShortcutsAtom = XInternAtom( QX11Info::display(), "_KDE_NETWM_BLOCK_GLOBAL_SHORTCUTS", False );

void
KRDC::blockGlobalShortcuts(bool yes)
{
  if (yes) {
    const char *data = "1";
    XChangeProperty(QX11Info::display(), window, blockGlobalShortcutsAtom, XA_ATOM, 32, PropModeReplace, (uchar*)data, 1 );
   }
else
   XDeleteProperty(QX11Info::display(), window, blockGlobalShortcutsAtom);
}

@Martin: Can you please read Thomas' last few comments and comment on it? Thank you.

I'm all for a handling of global shortcuts which makes sense.

What might also be a solution is using kwin scripting. Since we can now inject scripts and stop scripts through the dbus interface it just needs the property to set global shortcuts.

(In reply to comment #45)
> I'm all for a handling of global shortcuts which makes sense.
> 
> What might also be a solution is using kwin scripting. Since we can now inject
> scripts and stop scripts through the dbus interface it just needs the property
> to set global shortcuts.

Thanks for your reply. Do you think you will find some time to work on this? If not, can you please give me some hints how to get something like that done?

> Thanks for your reply. Do you think you will find some time to work on this?
> If not, can you please give me some hints how to get something like that
> done?
this needs first to be evaluated further. Just yesterday I read - I think on 
kcd - that mjansen wants to move block global shortcuts from KWin to the 
shortcut subsystem.

chances this can be addressed with KF5/Wayland?

I have this problem as well.

Arch Linux (x86_64)
KDE 4.14.3
KRDC 4.14.3

I have experienced this problem when virtualizing Windows XP, then I would access through RDP and I would press alt+tab and F4, etc. Which would result in just switching to another window on KDE or closing KRDC.

12 years already!!!!!

confirmed on KRDC 19.12.3 on KDE frameworks 5.68.0 w/ Qt 5.12.8