panned screens still needs `xtestIsXineramaUnaware` option enabled. this change
forcefully uses XTest only when leaving
useful examples:
* double 1 FullHD screen (main output) by:
`xrandr --fb 3840x1080 --output DP-1 --panning 3840x1080+0+0/3840x1000+0+80`,
leaving top 80 pixels for moving mouse out without actual panning
* dedicate right half of framebuffer to FullHD TV (second output):
`xrandr --fb 3840x1080 --output HDMI-0 --panning 1920x1080+1920+0`
feat: get windows building with the UNICODE forced by using Qt
refactor: remove ARCHString use QString to convert to / from utf8
build: (arch) link to common
build: (base) link to arch
build: (io) Link to common
build: (client) link to common
build: (server) link to common
fix: Append to log file instead of creating a new one each log line
refactor: Trim cipher description for neater log output
fix: Update log messages to use wide string format for Unicode support
fix: Correct event creation to use wide string for Unicode compatibility
refactor: Use QStringDecoder for UTF-8 handling on Windows Daemon child process
fix: Use correct wide type for Win32 consts
In the X11 code, we mapped hyper to super, so perhaps it makes sense to do that here too:
`src/lib/platform/XWindowsUtil.cpp`
```
case XK_Super_L:
case XK_Super_R:
case XK_Hyper_L:
case XK_Hyper_R:
return kKeyModifierBitSuper;
```
Some modifiers, notably LevelThree, were not accounted for in the
modifier mask calculation. This leads to an incorrect keymap where some
key symbols were listed for keys without (or insufficient) modifiers.
Emulating those keys can then produce the wrong keysyms.
Reproducible with server and client on English(UK) layout and typing
e.g. [. That key has its own key AD11 (right of P) but is also on
the third level of AE08 (the 8 key). When the server sends the keyid 91
(for [) the client looks it up in the pre-generated keymap. It is found
first on the 8 key with no modifiers (because LevelThree was previously
ignored), hence the client simulates a key 8 press without modifiers.
This erroneously produced an 8 instead of the wanted [.
Fix this by ensuring that all modifiers are accounted for in the key
map. This fix is likely incomplete as it does not account for the full
virtual modifier to real modifier mappings possible (e.g. Mod5 *may* be
something other than AltGr) but it does push the can a bit further down
the road, for someone else to release the worms.
Closes: #8168
For the longest time, this log line has bugged me:
```
active sides: e
```
It's hex, but it looks like a bug, since there's no `0x` prefix. Also, most humans can't read hex, so I added a string representation.
New version:
```
[2025-08-06T11:56:00] DEBUG: active sides: LRT (0x0e)
```
