- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR10015: win32u: Actually return HKL for SPI_GETDEFAULTINPUTLANG. - approved
by Alexandre Julliard (＠julliard) Feb. 3, 2026

Feb. 3, 2026

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

1 0

[PATCH v2 0/1] MR10005: Draft: [RFC] server: Add option to return ticks since wineserver start.
by Bernhard Übelacker Feb. 3, 2026

Feb. 3, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59287 - Unsure if there is a better way to make this configurable? - Is adding the message to GetTickCount ok for performance reasons? How can a user be better warned if they have an uptime above 25 days and their application uses this Api? -- v2: Draft: server: Add option to return ticks since wineserver start. https://gitlab.winehq.org/wine/wine/-/merge_requests/10005

1 2

Re: [PATCH v4 0/9] MR9987: opengl32: Generate extension lists with basic GLES support.
by Elizabeth Figura (＠zfigura) Feb. 3, 2026

Feb. 3, 2026

> I don't really know well but it seems to me that GL_APPLE_fence is a fallback for GL_ARB_sync, and GL_APPLE_flush_buffer_range a fallback for GL_ARB_map_buffer_range. I'm not sure about GL_APPLE_rgb_422 and GL_APPLE_ycbcr_422 but I suppose that they aren't available outside of macOS, and the latter described as only available on legacy contexts, so I assume they are only optional for wined3d operation? Sort of. While we use ARB_sync and APPLE_fence in more or less the same way, I don't think the semantics of ARB_sync are a subset of those of APPLE_fence in general. In fact they are probably a superset if anything. It wouldn't be appropriate to implement ARB_sync on top of APPLE_fence. The reason we fall back is because an implementation might expose APPLE_fence but not ARB_sync. I don't know for sure but it wouldn't surprise me if Apple machines do this very thing. That's the case for many extensions, including APPLE_flush_buffer_range vs ARB_map_buffer_range. In the case of YUV, we have fallback implementations, since, as you mention, those extensions aren't actually exposed outside of Mac as far as I know. They do require more work on our part, but I wouldn't be surprised if they're not actually less efficient for that. Now that we require GLSL anyway, there may not really any point continuing to use the Apple extensions. I'm not really about to delete something from wined3d if it's not getting in the way, though, and I think that's the main point here. GL_APPLE extensions are just like any other vendored extensions. You see vendors implementing each others' extensions all the time. There's no reason to treat them separately, and I don't see why they'd be a problem for opengl32 translation. (GLX_APPLE_* would be another story, if any such extensions existed, but then the operative part there is really "GLX", and I assume we already filter out GLX_*.) If a Windows application did in fact choke on seeing any APPLE extensions, we could remove them, and decide what we want to do about that in d3d, but I don't think there's any reason to do that preemptively. In fact, I would be surprised if this happens, because looking now, it seems at least one Apple extension, namely APPLE_packed_pixels, is frequently implemented on both Linux and Windows, including the radeonsi machine I'm typing from. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9987#note_128701

1 0

[PATCH v9 0/4] MR10007: Support enabling/disabling IME on winewayland
by Ziia Shi (＠mkrsym1) Feb. 3, 2026

Feb. 3, 2026

Currently, IME is always enabled for all applications. This can cause some very annoying issues on winewayland. For example, fcitx takes over the character repeat functionality when enabled, and does it via repeatedly sending sequences of keyup/keydown, which leads to applications not being able to track hold duration of a button (can be reproduced on any game which requires holding a letter key). The spec states that the enable request should only be sent when a text edit is focused, and a disable request should be sent when it is unfocused. Windows provides a "similar-ish" mechanism: applications can use ImmAssociateContext/ImmAssociateContextEx to associate an IMC when IME should be enabled, and set associated IMC to null when it should be disabled. From my rather limited testing, it is implemented this way in Chromium/CEF, QT and Unity. Setting it to null internally results in deactivation of the currently associated context. This MR makes the ImeSetActiveContext function of the builtin IME utilize a new driver function to communicate activation status. It does not take into account which specific context was activated, thus semi-stub. This fixes behavior of applications using the above-mentioned components. I only implemented it for winewayland, it probably should also be implemented for winex11 too, but I'm not sure how. ~~Unfortunately this breaks IME input in Wine comctl32/user32 components. I am not sure how it is supposed to behave on Windows or how to test it at the current point, will look into it later. Having IME on by default appears to "fix" it, but that is very likely not the Windows behavior; moreover, at least Unity does not disable IME on start, which causes the above-mentioned issue to occur until a textbox is manually focused and unfocused.~~ Fixed -- v9: imm32/tests: Test which IME receives ImeSetActiveContext deactivation call after layout change https://gitlab.winehq.org/wine/wine/-/merge_requests/10007

3 7

Re: [PATCH v31 0/2] MR9414: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Feb. 3, 2026

Feb. 3, 2026

Rebased after code freeze. Will leave it untouched for review until i receive other advise. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_128691

1 0

[PATCH v2 0/1] MR10011: programs/explorer: Follow up c31e65fd3bde7, keep systray visible with taskbar enabled
by Twaik Yont (＠twaik) Feb. 3, 2026

Feb. 3, 2026

This is a follow-up to c31e65fd3bde71234668507a9e15780d567c0a51, which introduced a clear separation between a standalone systray window (show_systray) and the systray area embedded in the taskbar (enable_taskbar). While the standalone systray is correctly disabled when the shell taskbar is enabled, parts of the systray visibility logic still treated show_systray as a global on/off switch. As a result, WM_DISPLAYCHANGE would hide the systray entirely when show_systray was false, even though the taskbar (and its dedicated systray area) was enabled. This caused the systray and its balloons to disappear permanently after a display mode change in desktop=shell configurations. Adjust the visibility conditions so that an enabled taskbar always allows the systray to remain visible, restoring the behavior implied by c31e65fd3bde71234668507a9e15780d567c0a51 and preventing the systray from being hidden on display changes when it is embedded in the taskbar. -- v2: programs/explorer: Follow up c31e65fd3bde7, keep systray visible with taskbar enabled https://gitlab.winehq.org/wine/wine/-/merge_requests/10011

3 3

[PATCH 0/1] MR10011: programs/explorer: Follow up c31e65fd3bde7, keep systray visible with taskbar enabled
by Twaik Yont (＠twaik) Feb. 3, 2026

Feb. 3, 2026

This is a follow-up to c31e65fd3bde71234668507a9e15780d567c0a51, which introduced a clear separation between a standalone systray window (show_systray) and the systray area embedded in the taskbar (enable_taskbar). While the standalone systray is correctly disabled when the shell taskbar is enabled, parts of the systray visibility logic still treated show_systray as a global on/off switch. As a result, WM_DISPLAYCHANGE would hide the systray entirely when show_systray was false, even though the taskbar (and its dedicated systray area) was enabled. This caused the systray and its balloons to disappear permanently after a display mode change in desktop=shell configurations. Adjust the visibility conditions so that an enabled taskbar always allows the systray to remain visible, restoring the behavior implied by c31e65fd3bde71234668507a9e15780d567c0a51 and preventing the systray from being hidden on display changes when it is embedded in the taskbar. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10011

3 7

[PATCH 0/2] MR10004: jscript: Fix DISPATCH_METHOD | DISPATCH_PROPERTYGET in ES5+ modes.
by Gabriel Ivăncescu Feb. 3, 2026

Feb. 3, 2026

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

3 4

[PATCH v8 0/3] MR10007: Support enabling/disabling IME on winewayland
by Ziia Shi (＠mkrsym1) Feb. 3, 2026

Feb. 3, 2026

Currently, IME is always enabled for all applications. This can cause some very annoying issues on winewayland. For example, fcitx takes over the character repeat functionality when enabled, and does it via repeatedly sending sequences of keyup/keydown, which leads to applications not being able to track hold duration of a button (can be reproduced on any game which requires holding a letter key). The spec states that the enable request should only be sent when a text edit is focused, and a disable request should be sent when it is unfocused. Windows provides a "similar-ish" mechanism: applications can use ImmAssociateContext/ImmAssociateContextEx to associate an IMC when IME should be enabled, and set associated IMC to null when it should be disabled. From my rather limited testing, it is implemented this way in Chromium/CEF, QT and Unity. Setting it to null internally results in deactivation of the currently associated context. This MR makes the ImeSetActiveContext function of the builtin IME utilize a new driver function to communicate activation status. It does not take into account which specific context was activated, thus semi-stub. This fixes behavior of applications using the above-mentioned components. I only implemented it for winewayland, it probably should also be implemented for winex11 too, but I'm not sure how. ~~Unfortunately this breaks IME input in Wine comctl32/user32 components. I am not sure how it is supposed to behave on Windows or how to test it at the current point, will look into it later. Having IME on by default appears to "fix" it, but that is very likely not the Windows behavior; moreover, at least Unity does not disable IME on start, which causes the above-mentioned issue to occur until a textbox is manually focused and unfocused.~~ Fixed -- v8: winewayland: Implement SetIMEEnabled driver call. imm32: Call SetIMEEnabled in ImeSetActiveContext. win32u: Add SetIMEEnabled driver call. https://gitlab.winehq.org/wine/wine/-/merge_requests/10007

3 5

[PATCH v2 0/1] MR10017: comctl32 : center icon in LV_VIEW_ICON mode by adjusting icon position calculation.
by Maotong Zhang (＠xiaotong) Feb. 3, 2026

Feb. 3, 2026

Fix icon display issue in "Faststone Image Viewer". -- v2: comctl32 : center icon in LV_VIEW_ICON mode by adjusting icon position calculation. https://gitlab.winehq.org/wine/wine/-/merge_requests/10017

3 4