[winswitch] Unable to register on bugtracker + Win32 issues

[Antoine Martin]

>>> 1. Xpra fails to start if libintl-8.dll doesn't exist beside Xpra.exe:
>>> "The procedure entry point libintl_snprintf could not be located in the
>>> dynamic link library [...]\lib\libfontconfig-1.dll." Copying the
>>> libintl-8.dll in lib one level up works.
>> That's odd, I've tested a few builds on a clean VM and I didn't see this
>> error. Is this an alert box? Which shortcut do you run?
> 
> Yes, I uploaded screenshots to https://imgur.com/a/eD4NltE . The left
> dialog appears first and the right one immediately afterward.
> 
> There are several other copies of libintl-8.dll on my system, since a
> lot of open source software ships it. One of those might be getting
> picked up from PATH instead of the one in lib. Xpra.exe,
> Xpra-Launcher.exe and Xpra_cmd.exe all fail.
Yes, that must be it. That's a relief: I have verified and the ZIP file
you are having problems with does work fine on a clean system.

> After copying the dll from
> lib one level up, everything works.
Rather than moving the DLLs, I've changed the path search order:
http://xpra.org/trac/changeset/26483

This should fix the problem on your system.
There's a 4.1 beta build here:
https://xpra.org/beta/windows/

>>> 2. Setting --keyboard-raw=yes sends the Windows scancode as X11 keycode.
>>> This is not very useful as generally X11 keycode = PC/AT scancode + 8.
>>> Client should probably add 8 to the scancode (event.keycode) when
>>> connecting from Win32 to X11.
>> This is not enabled by default and it is not meant to be used across
>> operating systems.
>> This is only useful at present when the client and server OS are
>> identical. (ie: Linux to Linux, or Windows to Windows)
>> When a translation is going to be needed, don't use raw mode.
> 
> Is there any other way to _not_ have Xpra do keysym-based mapping though?
Whenever this approach has been attempted, there has always been
problems. I've just tried it again with an MS Windows client connecting
to a Linux seamless server, and it didn't go well.

> Use case: I use a heavily customized multilingual layout on Windows.
> When connecting to X11 boxen, I generally only need standard US layout.
> I would prefer that keys are mapped using the server-side Xkb layout
> starting from keycodes (as happens with VNC, NoMachine and such) to
> avoid funkiness.
> 
> Example of a problem: the [ key (scancode 0x1a) produces ä (adiaeresis)
> with my Windows layout. When I connect with Xpra, it sets Xkb layout
> "us" on the remote (my Windows layout has locale US so this is an
> acceptable guess). When I press the [ key, nothing happens because (as
> far as I can tell) Xpra server side doesn't know what to do with the
> keysym adiaeresis since it doesn't appear in the Xkb us layout. What
> would preferably happen is that the scancode/keycode gets passed to X as
> usual and eventually pops up as [.
You can try this server-side change (without --keyboard-raw):
http://xpra.org/trac/changeset/26486
It will use the keyval for any key that it fails to locate.
This should do what you want.

If not, please create a ticket with more details.

Cheers,
Antoine

> 
>  -Valtteri