September 2024 - Wine-gitlab

Re: [PATCH v2 0/1] MR6445: po: Update Finnish translation. - approved
by Alexandre Julliard (＠julliard) 04 Sep '24

04 Sep '24

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

1 0

Re: [PATCH v9 0/1] MR6440: win32u: Implement NtGdiDdDDIEnumAdapters. - approved
by Alexandre Julliard (＠julliard) 04 Sep '24

04 Sep '24

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

1 0

Re: [PATCH v2 0/2] MR6436: d3d10/tests: Fully check matrix types. - approved
by Alexandre Julliard (＠julliard) 04 Sep '24

04 Sep '24

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

1 0

Re: [PATCH v3 0/2] MR6401: uxtheme: Optimize drawing by avoiding unneeded TransparentBlt(). - approved
by Alexandre Julliard (＠julliard) 04 Sep '24

04 Sep '24

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

1 0

Re: [PATCH v6 0/10] MR6374: winewayland: Get rid of the wayland surface lock. - approved
by Alexandre Julliard (＠julliard) 04 Sep '24

04 Sep '24

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

1 0

[PATCH v2 0/1] MR5012: msi: Disable Browse Button when feature has no associated directory
by Fabian Maurer (＠DarkShadow44) 04 Sep '24

04 Sep '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56289 -- v2: msi: Disable Browse Button when feature has no associated directory https://gitlab.winehq.org/wine/wine/-/merge_requests/5012

3 8

[PATCH 0/7] MR6441: quartz: Register the classes from their native DLLs.
by Rémi Bernon 04 Sep '24

04 Sep '24

Similar to !6430 and !6362, this should make it possible to use native override for these classes. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6441

3 13

[PATCH 0/1] MR6445: po: Update Finnish translation.
by Topi-Matti Ritala (＠ritalat) 04 Sep '24

04 Sep '24

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

2 1

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Jacek Caban (＠jacek) 04 Sep '24

04 Sep '24

On Wed Sep 4 17:57:07 2024 +0000, Jacek Caban wrote: > > being able to register wrappers from win32u makes things simpler > because we then don't need a manual function in winevulkan to register > the objects, and the winevulkan thunks can call directly into win32u functions. > So you plan to manage some of rbtree handling in winevulkan while others > in win32u? That doesn't sound like a clean separation if the only > benefit is avoiding a few manual thunks in winevulkan. It seems cleaner > to have all of that on one side (probably winevulkan, but win32u is also > a possibility). > win32u doesn't need client handles for anything else, unless I'm missing > something. It means that if we'd keep that in winevulkan, the only thing > from `vulkan_object` struct that's needed by win32u would be a handle > and a parent. The handle requires an unpleasant union and the parent > needs casting to be useful. That makes me question if `vulkan_object` is > really all that useful... Having a dedicated per-type structs would > avoid both of those. You needs it for both the device and instance, why > not have two or so more? Actually, depending on other design details, win32u may sometimes need client handle, but then the same concerns apply as against the host handle. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_81106

1 0

Re: [PATCH v2 0/8] MR6427: winevulkan: Introduce a vulkan object structure.
by Jacek Caban (＠jacek) 04 Sep '24

04 Sep '24

> being able to register wrappers from win32u makes things simpler because we then don't need a manual function in winevulkan to register the objects, and the winevulkan thunks can call directly into win32u functions. So you plan to manage some of rbtree handling in winevulkan while others in win32u? That doesn't sound like a clean separation if the only benefit is avoiding a few manual thunks in winevulkan. It seems cleaner to have all of that on one side (probably winevulkan, but win32u is also a possibility). win32u doesn't need client handles for anything else, unless I'm missing something. It means that if we'd keep that in winevulkan, the only thing from `vulkan_object` struct that's needed by win32u would be a handle and a parent. The handle requires an unpleasant union and the parent needs casting to be useful. That makes me question if `vulkan_object` is really all that useful... Having a dedicated per-type structs would avoid both of those. You needs it for both the device and instance, why not have two or so more? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6427#note_81105

1 0