- Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR8689: dwrite: Implement dwritefactory3_GetFontDownloadQueue().
by Zhiyi Zhang (＠zhiyi) Aug. 1, 2025

Aug. 1, 2025

For React Native. -- v2: dwrite: Implement dwritefactory3_GetFontDownloadQueue(). dwrite: Add IDWriteFontDownloadQueue tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/8689

3 5

[PATCH v4 0/4] MR8555: windows.devices.enumeration: Reimplement DeviceInformationStatics::FindAllAsync and DeviceWatcher using the device query API.
by Vibhav Pant (＠vibhavp) Aug. 1, 2025

Aug. 1, 2025

Implement `DeviceWatcher` on top of a `HDEVQUERY` object, obtained from `DevCreateObjectQuery`. All events from the query object's associated callback are directly forwarded to the `DeviceWatcher`'s corresponding event handlers. As closing/freeing the `HDEVQUERY` is performed asynchronously, I have also added `IWeakReference` support for the device watcher. -- v4: windows.devices.enumeration: Implement DeviceInformationStatics::DeviceWatcher using DevCreateObjectQuery. https://gitlab.winehq.org/wine/wine/-/merge_requests/8555

3 6

[PATCH 0/6] MR8690: widl: Various metadata fixes
by Hans Leidekker (＠hans) Aug. 1, 2025

Aug. 1, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8690

3 7

[PATCH 0/1] MR8694: win32u: Clear DC opengl drawable when releasing cached dce.
by Rémi Bernon Aug. 1, 2025

Aug. 1, 2025

We won't be able to do it later on otherwise as get_dc_ptr will fail with a disabled DC, and release_dce will then not clear the drawable. This will delay the drawable release until the dce is later reused, for instance for a different window, which may cause a complicated deadlock. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8694

1 2

[PATCH 0/4] MR8692: windows.ui: Implement accessibilitysettings_get_HighContrast().
by Zhiyi Zhang (＠zhiyi) Aug. 1, 2025

Aug. 1, 2025

For React Native. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8692

2 4

[PATCH 0/2] MR8691: mshtml: Add IHTMLAttributeCollection4 stub implementation.
by Jacek Caban (＠jacek) Aug. 1, 2025

Aug. 1, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/8691

2 2

[PATCH 0/2] MR8689: dwrite: Implement dwritefactory3_GetFontDownloadQueue().
by Zhiyi Zhang (＠zhiyi) Aug. 1, 2025

Aug. 1, 2025

For React Native. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8689

3 4

[PATCH v2 0/2] MR8635: oleaut32: Fix VarAnd string conversion length handling
by Maotong Zhang (＠xiaotong) Aug. 1, 2025

Aug. 1, 2025

Determine type (I2, I4, I8) based on BSTR length. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56280' -- v2: oleaut32: Fix VarAnd string conversion length handling oleaut32/tests: Add more BSTR test cases for VARAND https://gitlab.winehq.org/wine/wine/-/merge_requests/8635

2 2

Re: [PATCH v2 0/1] MR8532: winegstreamer: Force h264parse to output 'au' aligned byte-stream.
by Brendan McGrath (＠redmcg) July 31, 2025

July 31, 2025

On Thu Jul 31 18:58:30 2025 +0000, Tim Clem wrote: > Ah, interesting. Thanks for looking in to that. I can't speak to any of > that, really - I'm not very familiar with winegstreamer at all. I was > more wondering if we needed to explicitly set `byte-stream`, and maybe > we don't?: tclem/wine!8. Not sure if the tests cover the initial issue > you were addressing though. And I guess if it fixates to AVC but doesn't > have the required `codec_data` then maybe `byte-stream` is the only > option. But like I said, that has broken h.264 on macOS. Yeah, sorry. I took a look yesterday in the hope of finding answers, but instead came away with more questions. But, as you probably already noticed, we do need that `stream-format=byte-stream` for `avdec_h264` to work. Otherwise we get a bunch of failed tests in `mf:transform`: https://gitlab.winehq.org/tclem/wine/-/jobs/178373#L2122 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8532#note_111763

1 0

[PATCH 0/5] MR8540: kernelbase: Handle reparse points in some high-level functions, part 1/2.
by Elizabeth Figura (＠zfigura) July 31, 2025

July 31, 2025

These do not do anything currently, since we don't support FILE_OPEN_REPARSE_POINT on the Unix side yet. However, they are correct, as demonstrated by the recently committed tests, and it seems prudent to get these out of the way for now. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8540

4 9