The MR adds implementations (+ a few tests) for the following methods in `bluetoothapis.h`:
* `BluetoothSdpEnumAttributes`
* `BluetoothSdpGetContainerElementData`
* `BluetoothSdpGetElementData`
* `BluetoothSdpGetAttributeValue`
--
v3: bluetoothapis/tests: Add test for BluetoothSdpGetAttributeValue.
bluetoothapis: Implement BluetoothSdpGetAttributeValue.
bluetoothapis/tests: Add unit tests for BluetoothSdpEnumAttributes, BluetoothSdpGetContainerElementData, and BluetoothSdpGetElementData.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6402
On Thu Aug 29 16:19:09 2024 +0000, Elizabeth Figura wrote:
> Actually, I'm a bit confused, because now I'm not sure where RPC does do
> that? I was assuming it was a user-marshalled type which implicitly
> calls DuplicateHandle(), but that's not the case.
> The lack of tests in this patch set is a little disturbing. Is it
> possible to test this behaviour? I don't know under what circumstances
> handle events are sent [and I can't easily find anyone successfully
> using DBT_DEVTYP_HANDLE online]. We do have support for testing PnP
> drivers, though, if that's necessary; see dlls/ntoskrnl.exe/tests/driver_pnp.c.
@zfigura Testing it is tricky. My plan was to utilize it in the bluetooth driver by directly calling `plugplay_send_event` from the driver code itself, and I'm not sure what the equivalent of that would be in Windows.
@rbernon I'm okay with using reserved as an offset to pass the device path, but we'd still have to pass it for every message for filtering. I didn't want to utilize `reserved` mostly out of caution, if it ever turned out to be that the field did have some undocumented semantics after all.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80493
The macOS Sequoia SDK has "obsoleted" this function: calling it
triggers a build error when targeting macOS Sequoia.
It can still be used though, either by targeting pre-Sequoia or by
getting a pointer to the function through dlsym().
This is intended to be temporary until ScreenCaptureKit.framework or
some other approach can be used (see !5935).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6403
The option is on by default with the virtual desktop, off by default
otherwise, but can be forced on/off in either case, letting it hide
the taskbar in virtual desktop mode too.
The standalone systray window still uses the separate ShowSystray option
which can be enabled when EnableShell is off. When EnableShell is on,
the systray area will always be visible in the taskbar.
--
v4: explorer: Use the EnableShell option to show or hide the taskbar.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6367