--
v3: server: Eliminate async_alerted() helper function.
server: Eliminate async_unknown_status() helper function.
server: Remove "unknown_status" field from struct async.
server: Remove "alerted" field from struct async.
server: Remove "terminated" field from struct async.
server: Remove "signaled" field from struct async.
server: Remove "direct_result" field from struct async.
server: Signal async unconditionally in async_set_result().
server: Introduce a new async state enum.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6369
This MR adds a unixlib component to wlanapi containing DBus + NetworkManager implementations for
* WlanEnumInterfaces
* WlanGetAvailableNetworkList
* WlanGetAvailableNetworkList
* WlanGetNetworkBssList
* WlanScan
--
v6: wlanapi: Add NetworkManager backed implementation for WlanScan.
wlanapi/tests: Add unit tests for WlanScan.
wlanapi: Add NetworkManager backed implementation for WlanGetNetworkBssList.
wlanapi/tests: Add unit test for test_WlanGetNetworkBssList.
wlanapi: Add NetworkManager backed implementation for WlanGetAvailableNetworkList.
wlanapi/tests: Add unit test for WlanGetAvailableNetworkList.
wlanapi: Add NetworkManager backed implementation for WlanEnumInterfaces.
wlanapi: Add a basic unixlib implementation.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6505
The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`:
* `BluetoothSdpEnumAttributes`
* `BluetoothSdpGetContainerElementData`
* `BluetoothSdpGetElementData`
* `BluetoothSdpGetAttributeValue`
--
v23: bluetoothapis: Implement BluetoothSdpGetAttributeValue.
bluetoothapis/tests: Add tests for BluetoothSdpGetAttributeValue.
bluetoothapis: Add stub for BluetoothSdpGetAttributeValue.
bluetoothapis: Implement BluetoothSdpEnumAttributes.
bluetoothapis/tests: Add tests for BluetoothSdpEnumAttributes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6402
On Wed Sep 18 15:58:22 2024 +0000, Nikolay Sivov wrote:
> I think it is, because it will produce incorrect rendering. First
> priority is to have it working correctly, then we can deal with possible duplication.
TBH, I do not really know what to make of this assessment. Looking at the d2d1 tests it feels like, correctness is at best achieved approximately, and then the question arises what is the metric in which "correctness" is assessed? Unarguably, the tests as a metric are a moving target, depending on when which tests are added, thus making it a subjective choice at times.
In my book, the patch at hand makes the rendering more correct in many cases. To be precise in all cases in which the individual geometries in the geometry group do not intersect, and thus the fill mode does not matter. Would you consider the patch sufficient, if it would (approximately) check for intersections and only copy if there are none, and falling back to old behavior (rendering just nothing) in case there are any (potentially false-positive) intersections?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6492#note_82945