[winswitch] Unable to register on bugtracker + Win32 issues

[Valtteri Vuorikoski]

On 2020-05-26 13:21, Antoine Martin wrote:
> On 26/05/2020 01:38, Valtteri Vuorikoski via shifter-users wrote:
> Thank you for reporting this problem. A recent system update had broken
> the tracker registration page. This should be fixed now.

Great, thanks.

>> The issues I was going to report are simple so I'll just put them here
>> for now (both Win32 with 4.0.1, using the zip version):
> Which exact version? (32 or 64-bit, python2 or python3, client-only
> build? etc)
> Can you give us the MD5 sum of the ZIP file you used?

The zip file available on the download page, which contains 
Xpra-Python3-x86_64_4.0.1-r26379. zip md5sum: 
ada76608e7b98d55d958f9820f6c0693

>> 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. After copying the dll from 
lib one level up, everything works.

>> 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?

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 [.

  -Valtteri