Thanks for feedback @rbernon. I'll take a closer look to see if there are any other outstanding yabridge issues preventing merges.
I'll also gather all the relevant patches considered tested by the bug comments vs all the other irrelevant wine-staging patches that were also included.
Regardless whatever remaining broken state yabridge may still be in need of a fix, your yabridge new-wine10-embedding is in a far better and functioning state.
If yabridge devs approve new-wine10-embedding for merge then that will be reflected here to attempt a merge of the relevant wine-staging changes into upstream which will be required by the yabridge merge approval.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113254
Thanks for the update. FWIW I'm not aware of any wine-staging patch helping with yabridge, although it's possible I may be missing something. I believe there was a couple of remaining issues which is why the yabridge branch hasn't been merged but I haven't looked closely into them (anybody is welcome to have a try).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113253
Yabridge bug has been updated with latest test results regarding this merge request patches applied with wine-staging patches against commit 75b9e1722d1 Release 10.13 on Debian 13: https://bugs.winehq.org/show_bug.cgi?id=58552
Confirming @rbernon contributions to yabridge fix the GUI offset mouse misalignment when built and run with latest wine-staging patches: https://github.com/robbert-vdh/yabridge/tree/new-wine10-embedding
Until relevant wine-staging patches are merged with upstream, yabridge new-wine10-embedding branch exists in a limbo state that complicates vanilla distro releases of yabridge because the relevant wine-staging patches are missing from vanilla wine distro releases.
If wine-patches are still pending per more user testing then updates to the bug report partly fulfill that dependency.
Yabridge equivalent bug report to WineHQ for ref: https://github.com/robbert-vdh/yabridge/issues/409
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113250
MobaXTerm tries to ShellExecute "/bin/sh" when running under wine. This ability
to run unix executables on the host via unix paths was accidentally removed
in the attemp to align ShellExecute more closely with native, while fixing the
problem that sometimes wrong executable is started by ShellExecute (e.g. in
Motor Race Collection).
Related: a2548c8db3096963012939c82e340f6b867f3efd
Fixes: 85d029e3b01f6dd35a86cc07796af982d66e4a03
--
v3: shell32: Restore the ability of running unix executables via unix paths
https://gitlab.winehq.org/wine/wine/-/merge_requests/8794
Keyboard cues are disabled by default on newer versions of Windows. Some win32 common controls, e.g., button doesn't draw a focus rect when SystemParametersInfoW(SPI_GETKEYBOARDCUES) reports FALSE.
Drawing a focus rect when the button is really small creates an effect that makes the button look corrupted. On Windows, the focus rect is not drawn when keyboard cues are disabled, which is the default.
Other controls also have this behavior, so they're included as well. There are some exceptions, for example, SysMonthCal32 always draws a focus rect, even when keyboard cues are disabled.
--
v2:
https://gitlab.winehq.org/wine/wine/-/merge_requests/8763
Keyboard cues are disabled by default on newer versions of Windows. Some win32 common controls, e.g., button doesn't draw a focus rect when SystemParametersInfoW(SPI_GETKEYBOARDCUES) reports FALSE.
Drawing a focus rect when the button is really small creates an effect that makes the button look corrupted. On Windows, the focus rect is not drawn when keyboard cues are disabled, which is the default.
Other controls also have this behavior, so they're included as well. There are some exceptions, for example, SysMonthCal32 always draws a focus rect, even when keyboard cues are disabled.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8763