July 2023 - Wine-GitLab - list.winehq.org

Re: [PATCH v3 0/1] MR3222: localspl: Add workaround for old versions of cups.h - approved
by Alexandre Julliard (＠julliard) July 7, 2023

July 7, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3222

1 0

Re: [PATCH v2 0/6] MR3261: Remove DECLSPEC_HIDDEN macro various dlls. - approved
by Alexandre Julliard (＠julliard) July 7, 2023

July 7, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3261

1 0

Re: [PATCH v2 0/3] MR3246: Better handling when debuggee terminates when attaching to it. - approved
by Alexandre Julliard (＠julliard) July 7, 2023

July 7, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3246

1 0

Re: [PATCH v5 0/8] MR3249: windows.networking.hostname: Implement IHostNameFactory::CreateHostName(). - approved
by Alexandre Julliard (＠julliard) July 7, 2023

July 7, 2023

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3249

1 0

[PATCH v2 0/1] MR3247: d3d11/tests: Add basic test for shared resources.
by Paul Gofman (＠gofman) July 7, 2023

July 7, 2023

-- v2: d3d11/tests: Add basic test for shared resources. https://gitlab.winehq.org/wine/wine/-/merge_requests/3247

3 6

Re: [PATCH v15 0/7] MR3189: Add windows.devices.geolocation.geolocator
by Rémi Bernon July 7, 2023

July 7, 2023

On Fri Jul 7 19:27:44 2023 +0000, Fabian Maurer wrote: > Do you want me to create a new MR where I rename it? I agree that it > should be in the correct dll, sorry for messing that up. Please do. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38337

1 0

Re: [PATCH v15 0/7] MR3189: Add windows.devices.geolocation.geolocator
by Fabian Maurer (＠DarkShadow44) July 7, 2023

July 7, 2023

On Fri Jul 7 08:04:06 2023 +0000, Rémi Bernon wrote: > Sorry, I should've checked that. > Fwiw if the module doesn't export anything in particular it should not > really matter how it's named, the classes are registered with whatever > module implements them and the code reads the module name from the registry. Do you want me to create a new MR where I rename it? I agree that it should be in the correct dll, sorry for messing that up. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3189#note_38336

1 0

[PATCH 0/14] MR3266: mshtml: dom tests leak fixes.
by Gabriel Ivăncescu July 7, 2023

July 7, 2023

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

2 15

[PATCH 0/6] MR3238: wined3d: Move Vulkan declarations to wined3d_vk.h, part 1/3.
by Zebediah Figura (＠zfigura) July 7, 2023

July 7, 2023

This is a part of a larger effort to reorganize wined3d a bit so that backend functions are fully quarantined into their own files. There are a few advantages to this: * We avoid including (large) headers in files that don't need them. * This has helped me find functions that are currently incorrectly tied to backends [e.g. wined3d_texture_update_desc(), wined3d_texture_set_lod()]. * This may also help find code (struct members, helpers, etc.) which should be made local to a backend. * I find that this aids the reader in logically separating wined3d code. For some time the wined3d code base has resisted modularity of compilation units, simply on the grounds that this is not necessary. I find files comprising several thousand lines to be a bit unwieldy, however, and that comprehension and navigation are eased when drawing physical lines even when such separation was already obvious. It also can be nice for compilation speed. There are a few steps to this: - move GL and Vulkan declarations to wined3d_gl.h and wined3d_vk.h respectively - introduce "resource_gl.c" and "resource_vk.c", and move most resource code to those functions. This collapses the separation between buffer, texture, sampler, and view code, though, and there may be some benefit in keeping those separate. It's worth mentioning though that the bulk of those files ends up being the texture code. It's also worth mentioning that resources are generally interrelated—e.g. views delegate to buffers or textures—and we've talked about generalizing more of the buffer/texture code to share more code. Of course, *everything* is interrelated, so the lines that we're drawing now are kind of arbitrary. I at least find that GL/Vulkan are *useful* lines to draw. - add format_gl.c, because there are about 3000 lines of code to deal with GL format detection. - add ffp_gl.c, which contains the fixed-function vertex and fragment pipelines. This is about 3500 lines. - move other functions to backend-specific adapter or context functions, where it makes sense. Swapchain code mostly gets moved to context_*.c, though I'm not sure whether that makes the most sense or not. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3238

5 11

[PATCH 0/1] MR3265: gdi32: Fix DIB_PAL_INDICES usage handling in EMR_CREATEMONOBRUSH playback.
by Piotr Caban (＠piotr) July 7, 2023

July 7, 2023

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55177 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3265

3 2