June 2024 - Wine-GitLab - list.winehq.org

Re: [PATCH v4 0/9] MR5782: win32u: Move UpdateLayeredWindow implementation to win32u. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v2 0/6] MR5763: wined3d: Fix some corner cases in the FFP pipelines related to unbound streams. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v3 0/1] MR5786: gdi32: Use an internal NtUser call for D3DKMTOpenAdapterFromGdiDisplayName. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v2 0/1] MR5795: scrrun/dictionary: Implement putref_Item() method. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v4 0/1] MR5749: gitlab: Update configuration for the new Mac runner. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v3 0/1] MR5779: win32u: Send EVENT_OBJECT_FOCUS in more cases. - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

Re: [PATCH v3 0/5] MR5791: wineps.drv: Page size and orientation fixes - approved
by Alexandre Julliard (＠julliard) June 5, 2024

June 5, 2024

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

1 0

[PATCH v33 0/1] MR5752: msvcrt: [PR53960] Fix ucrt has different struct layout than msvcrt
by cqwrteur (＠trcrsired) June 5, 2024

June 5, 2024

UCRT's FILE struct and fd struct have different layouts, and their locks are different. Implementation in Wine does not match UCRT in Windows, causing ABI issues. see: https://bugs.winehq.org/show_bug.cgi?id=53960 -- v33: [PATCH] msvcrt: Fix incorrect layout of FILE in ucrt https://gitlab.winehq.org/wine/wine/-/merge_requests/5752

3 2

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu June 5, 2024

June 5, 2024

On Wed Jun 5 18:25:43 2024 +0000, Jacek Caban wrote: > > Well yes, of course they check for the object type compatibility, but > in the end they should still preserve their "function identity" instead > of being looked up from the object everytime, even if it's completely > detached from it. > I don't know what you mean by that, a pair like (dispid, iid) uniquely > defines a function identity. There is nothing special about dispid > except that we already need its lookup implemented, so that seems convenient. > See https://gitlab.winehq.org/jacek/wine/-/commits/func-call for a draft > of what I mean. It implements `call` only for legacy functions, but I > think it would scale to proper prototypes. It implements > bc02a4fe3be595448, but doesn't need unpleasant things like > `get_dispex_from_this` and uses the new interface instead (so committing > something like that would also be a good opportunity to upstream > "boring" parts of 81800d9dfa59f4fd8). > Extending it with accessors support should be straightforward. For > prototypes, we could just have entries for those functions both in the > instance and prototype objects. In instances, they would be not searched > when doing lookups by name, so the only way to use it would be through > `IJSDispatchHost`. For prototypes, they would be looked up, but an > attempt to call it would fail because prototypes don't actually > implement the required interface (so the result of the lookup would be > useful only for instances). It should also allow skipping 1ffeaa446613 > with all its consequences. What do you think? Well yes, a pair does work, but I wasn't passing the IID, only the DISPID after making sure the object implements the required IID, since I was delegating to the standard InvokeEx (well, almost), which only has DISPID. But it was still ambiguous as I explained. But since we pass the mshtml-internal tid (called iid in args) which is opaque to jscript, I don't really see why this is better than passing the `func_info_t` directly? Well IMO passing the pair is already more complex and requires more lookups, more args, etc, but that's just me. I haven't analyzed the rest yet, I'll look tomorrow as I have to go now, but `get_dispex_from_this` is primarily useful for jscript proxies since they can have arbitrary "this" passed. I was using it here (for legacy function.call) mostly to introduce it earlier and have less to add on the proxy patch which was already big enough as it is, but it's not its main purpose. It was just a "split" attempt. Are you sure you can get rid of it with your method? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_72511

1 0

[PATCH v4 0/4] MR5741: server: Implement key auto-repeat.
by Alexandros Frantzis (＠afrantzis) June 5, 2024

June 5, 2024

This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions: 1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code). 2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves). Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all). -- v4: win32u: Implement keyboard auto-repeat using new server request. server: Implement key auto-repeat request. server: Check message target process for raw input device flags. https://gitlab.winehq.org/wine/wine/-/merge_requests/5741

3 12