Key combinations cannot be used in a remote enviroment (virtual desktop)

[engelhro]

Hello,

A wonderful new and promising candidate to replace the outdated WinCompose, with sane defaults for the key combos and low need to customize the settings! Although there is a fork, that one seems to be maintained only sporadically…

BUT:

While Compose-for-Windows works perfectly locally, I have a major problem using it for inputs into a VDI (virtual desktop environment), in my case via Omnissa (previously VMWare).

• Key combos entered on the host are interpreted correctly and entered into each open application.

• But key combos entered in the remote client do not work. This is independent of the actual compose key chosen (in my case it is "CAPS LOCK").
  All keys appear as pressed and have their original meaning (so in my case the caps lock gets actually activated).

  So the hook to intercept the key combos and send the replacement to the application does not function for some reason. Also running Compose-for-Windows in the VDI client doesn't change anythingm probably the key combos do not ever reach the application there as expected.

This issue does not appear with WinCompose. For that tool most (in the past this was even "all", but some Omnissa updates during the last year seem to have ruined a few combinations) special characters are interpreted correctly on the host and then sent to the VDI successfully.

Is there a chance to change/update the behavior of Compose-for-Windows so it can also be used in combination with remote clients? Im happy to support in testing any fixes.

Thanks a lot!

[Coises]

@engelhro:

Thank you for the report.

I’m not able to reproduce this in the only similar setting I have: using built-in Windows Remote Desktop on a Windows 10 machine to control a Windows 7 machine. That works (with Compose for Windows running on the Windows 10 machine).

So I’m a bit unsure how to work out what the problem might be. You say WinCompose works for most combinations. At first glance it looks like WinCompose is using the same hook as Compose for Windows.

You also say, regarding WinCompose, that “some Omnissa updates during the last year seem to have ruined a few combinations.” Is there a pattern? Can you tell me what those key strokes are? I don’t know C#, so my ability to read the WinCompose source will be limited, but I might be able to figure out what is different about the way working and failing keystrokes are processed.

I don’t want to hold out a lot of hope that I’ll be able to fix this. My guess at the moment is that Omnissa also intercepts keystrokes and that there will prove to be a fundamental incompatibility between the way Compose for Windows processes them and the way Omnissa processes them.

[reinob]

I just tried the tool in a Windows VM (node2), connecting via RDP from another Windows PC (node1)
(CK4Win is installed in both).

With my short testing I can say that C4KWin works also within the RDP session.
However, the CAPS LOCK (which I also use as my COMPOSE key, in both nodes), seems to also be noticed by node1, so that the keyboard LED activates/deactivates (this doesn't happen when I use the COMPOSE key directly in node1.

(I can't say how the behaviour was with WinCompose, which I also (occasionally) used in the past.. either I didn't notice this, or it didn't happen).

[engelhro]

Hello,

Thanks for the quick reply in your attempt to help!

[...]

You also say, regarding WinCompose, that “some Omnissa updates during the last year seem to have ruined a few combinations.” Is there a pattern? Can you tell me what those key strokes are? I don’t know C#, so my ability to read the WinCompose source will be limited, but I might be able to figure out what is different about the way working and failing keystrokes are processed.

I was quite busy the last two weeks and will also be next week, but afterwards I can try to compile a list of some key combinations that work in WinCompose as expected and some that do not (any more).

I'll then also describe more details on the occasional hiccups I see with WinComposel, maybe this also helps in narrowing own the problem.

And yes, I have to admit that CAPS LOCK is probably not the easiest key and might be more problematic than others, but for me it's a reasonable choice as I don't use that key and it would be a dead key for me otherwise. I'll still try whether another trigger key shows the same problem (in WinCompose).

I don’t want to hold out a lot of hope that I’ll be able to fix this. My guess at the moment is that Omnissa also intercepts keystrokes and that there will prove to be a fundamental incompatibility between the way Compose for Windows processes them and the way Omnissa processes them.

I see, but thanks for your support nevertheless 🙏. I still hope this can get resolved somehow (as in WinCompose it works at least partially, but not at all in Compose-for-Windows…). I would make Compose-for-Windows usable for me also when working on a remote machine as I like it quite a lot and I think it might become a very decent replacement for the dated WinCompose in all my environments.

We'll see…

Summary

I'll add another comment here as soon as I have something more substantially to report, please leave the issue open until then.