The application crashes when attempting to load fonts internally, especially those with watermark functionalities. Reset the installedFontCollection.count field to zero upon release.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4138
A few recent changes broke the macOS build. Unfortunately nobody noticed, because the macOS CI job always fails. :-(
However, we can still fix that. I'm not sure that the last commit is the best approach, would like to have comments from Henri.
--
v2: include: Import vkd3d_d3dcompiler.h instead of redefining D3D_BLOB_PART.
vkd3d-shader: Explicitly cast vkd3d_shader_global_flags to uint64_t.
ci: Allow the artifact copy to fail.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/423
A few recent changes broke the macOS build. Unfortunately nobody noticed, because the macOS CI job always fails. :-(
However, we can still fix that. I'm not sure that the second commit is the best approach, would like to have comments from Henri.
--
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/423
@afrantzis Can't seem to be possible to add you as a reviewer, probably you need to request "Access" to the wine/wine project (near the top of the project page).
What do you think of something like that? It is very different from the current winex11 code, but I believe it will match keyboard layouts in a much more accurate way, and it's also IMO much simpler. If that works well with Wayland, I think it could be a good hint that it might work as well in X11 and make a case for my other MR to use that approach there.
I was a bit annoyed that it doesn't seem possible to retrieve the Xkb "layout:variant" string here, but only the layout description, so I had to use xkbregistry to match it back to the known layouts.
It is mostly only there to provide a more accurate HKL value (which should match the layout langid), and scan to vk mapping table, and custom layouts should still work. The lang would be neutral then, and the scan to vk table is QWERTY by default, which is the most common case, and doesn't enforce any vkey -> unicode mapping anyway. So, if the xkbregistry dependency is an issue we could probably make it optional and dynamically loaded, and skip the langid and scan to vk specialized mappings.
--
v2: winewayland.drv: Implement Xkb composition using ImeProcessKey.
winewayland.drv: Translate Xkb keyboard layouts to KBDTABLES.
win32u: Allow KBDTABLES conversion from CTLR + ALT to WCHAR.
win32u: Force US layout in ToUnicode when CTRL is pressed.
win32u: Introduce KbdLayerDescriptor user driver entry.
win32u: Avoid accessing NULL key name string pointer.
winewayland.drv: Enumerate Xkb layouts and create matching HKL.
winewayland.drv: Handle and parse Xkb keymap events.
win32u: Implement opt-in auto-repeat for WM_(SYS)KEYDOWN messages.
winewayland.drv: Configure win32u keyboard repeat delay and speed.
winewayland.drv: Basic handling of Wayland keyboard events.
gitlab: Install libxkbcommon and libxkbregistry dependencies.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4102
Yeah, but this isn't necessarily about not trusting Windows apps, i.e. malice or malware, but rather that they can't be designed around it (since they assume Windows environment), so they would have privacy issues without even wanting to. At the very least maybe use `sd_id128_get_machine_app_specific` with a unique app ID for Wine? Simple and still better than nothing.
Otherwise, it would probably have to be done per-prefix (registry?), since two processes in the same prefix might want the same ID.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4108#note_49432