Elizabeth Figura pushed to branch master at wine / wine-staging
Commits:
ebf36e47 by Elizabeth Figura at 2025-04-09T16:47:07-05:00
d3dx9_36-DDS: Remove patch.
This was implemented upstream by e12a1d283a0d4a14c2394a05052b06f0de16f1a6.
- - - - -
4fa7fcd6 by Elizabeth Figura at 2025-04-09T17:11:35-05:00
Rebase against 647004cd5d7ee93ad8b53abb8939da87be3e25a0.
- - - - -
9 changed files:
- − patches/d3dx9_36-DDS/0002-d3dx9_36-Improve-D3DXSaveTextureToFile-to-save-simpl.patch
- − patches/d3dx9_36-DDS/definition
- − patches/user32-Dialog_Paint_Event/0001-user32-Call-UpdateWindow-during-DIALOG_CreateIndirec.patch
- − patches/user32-Dialog_Paint_Event/definition
- patches/user32-Implement-CascadeWindows/0001-user32-Implement-CascadeWindows.patch
- patches/user32-Implement-CascadeWindows/0002-user32-Implement-TileWindows.patch
- − patches/user32-alttab-focus/0001-Send-WM_NCPOINTERUP-on-focus-regain.patch
- − patches/user32-alttab-focus/definition
- staging/upstream-commit
View it on GitLab: https://gitlab.winehq.org/wine/wine-staging/-/compare/835c92a2980d221a14e57…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine-staging/-/compare/835c92a2980d221a14e57…
You're receiving this email because of your account on gitlab.winehq.org.
Alexandre Julliard pushed to branch master at wine / wine
Commits:
bb850137 by Rémi Bernon at 2025-04-09T22:49:42+02:00
explorer: Paint the desktop even without RDW_ERASE.
- - - - -
81a24edc by Rémi Bernon at 2025-04-09T22:49:42+02:00
winex11: Avoid setting RDW_ERASE on expose events.
The Medium launcher uses a dialog window procedure, and implements its
background by doing a StretchBlt call on WM_PAINT in the dialog
procedure call, which happens before the window message loop
It then itself calls InvalidateRect(hwnd, NULL, 0), which queues a
WM_PAINT as well but with only the RDW_INVALIDATE flag.
Next, when the window message loop is executed, the WM_PAINT message is
being processed as it should, but as we've invalidated the window with
RDW_ERASE from the expose event, the WM_NCPAINT handler erases the
entire window, clearing the pixels that the launcher has just painted.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57665
- - - - -
2 changed files:
- dlls/winex11.drv/event.c
- programs/explorer/desktop.c
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/6b7963037f935f7fc20e2278e1916…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/6b7963037f935f7fc20e2278e1916…
You're receiving this email because of your account on gitlab.winehq.org.
Alexandre Julliard pushed to branch master at wine / wine
Commits:
b562f31f by Elizabeth Figura at 2025-04-09T22:49:42+02:00
user32/tests: Test messages when creating a visible modeless dialog.
- - - - -
6b796303 by Sebastian Lackner at 2025-04-09T22:49:42+02:00
user32: Call UpdateWindow() after showing a dialog.
This partially reverts 52146f62fd28bc1a791734b9939378267140b095.
As stated in that commit, a WM_PAINT will eventually be generated via window
exposure. However, some applications rely on WM_PAINT being sent synchronously.
As create_visible_dialog_seq shows, this happens reliably, and the behaviour is
specific to dialogs.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=35652
- - - - -
2 changed files:
- dlls/user32/dialog.c
- dlls/user32/tests/msg.c
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/b568eaac4aeb307d289ae69924574…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/b568eaac4aeb307d289ae69924574…
You're receiving this email because of your account on gitlab.winehq.org.
Alexandre Julliard pushed to branch master at wine / wine
Commits:
600c5a9a by Piotr Caban at 2025-04-09T21:06:29+02:00
conhost: Allow raster fonts.
- - - - -
1a9bbb0c by Piotr Caban at 2025-04-09T21:06:29+02:00
conhost: Merge validate_font and validate_font_metric helpers.
- - - - -
8769b19b by Piotr Caban at 2025-04-09T21:06:29+02:00
conhost: Imrove best matching font selection in set_first_font.
Otherwise, on systems with only Wine provided fonts, we end up selecting
first non-vertical font ignoring other properties.
- - - - -
53ad843d by Piotr Caban at 2025-04-09T21:06:29+02:00
conhost: Prioritize font charset when selecting initial font.
- - - - -
1 changed file:
- programs/conhost/window.c
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/993c079371a2e4bcf88a60c998290…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/compare/993c079371a2e4bcf88a60c998290…
You're receiving this email because of your account on gitlab.winehq.org.
Alexandre Julliard pushed to branch master at wine / wine
Commits:
c0a81478 by Byeong-Sik Jeon at 2025-04-09T12:22:54+02:00
win32u: Support WM_IME_KEYDOWN message during ImeProcessKey.
In Korean input, when ime is in the composition state, if a non-printable key
(ENTER, HOME, etc) is pressed, it returns a result_string and passes the key
to WinProc with the WM_IME_KEYDOWN message.
This can be seen in ‘imm32/test/imm32.c::test_ga_na_da()’.
In the current winemac.drv, if I select the “Korean 2-Set Keyboard” as the
input source and type ‘r-k-ENTER’, it only returns the result string ‘0xAC00’.
No WM_IME_KEYDOWN message is generated.
At this point, the WINE_IME_POST_UPDATE call occurs and macdrv_ImeProcessKey
returns FALSE. A FALSE return value means that the key has not been consumed
by ime and the key should be passed to the WinProc as a raw WM_KEYDOWN.
However, because the ime_update call have occurred, ImeProcessKey should return
TRUE and a raw WM_KEYDOWN message should be generated via a different path.
So a WM_IME_KEYDOWN message is required.
This patch allows the macdrv_ImeProcessKey return value to be passed to
ImeToAsciiEx() to determine if a WM_IME_KEYDOWN message should be generated.
- - - - -
4 changed files:
- dlls/imm32/ime.c
- dlls/win32u/imm.c
- dlls/wow64win/user.c
- include/ntuser.h
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/commit/c0a81478f52eb56d9778adb995556f…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/commit/c0a81478f52eb56d9778adb995556f…
You're receiving this email because of your account on gitlab.winehq.org.
Alexandre Julliard pushed to branch master at wine / wine
Commits:
b52ff2d6 by Byeong-Sik Jeon at 2025-04-09T12:22:42+02:00
win32u: Preserve result string from multiple WINE_IME_POST_UPDATE calls during ImeProcessKey.
In winemac.drv, there are multiple ime update calls occur during ImeProcessKey.
These multiple ime update calls need to be properly merged into ‘data->update’.
However, currently win32u/imm.c::post_ime_update() only keeps the last ime
update call.
Valid rules are:
- The previous comp_str is discarded when the new ime update call occurs,
so it is only valid if the last ime update call comp_str is not NULL.
- The previous result_str is kept if the new ime update call result_str is NULL.
- If both the previous and the new ime update call result_str are not NULL, then
concatenate them.
Test key sequences are:
- "Japanese Romanji" : 'nihongo-SPACE-n'
- "Korean 2-Set Keyboard" : 'r-k-s-k'
- "Korean 2-Set Keyboard" : 'r-k-1" or 'r-k-SPACE'
- - - - -
1 changed file:
- dlls/win32u/imm.c
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/commit/b52ff2d69961bd1f3adc7ba386f179…
--
View it on GitLab: https://gitlab.winehq.org/wine/wine/-/commit/b52ff2d69961bd1f3adc7ba386f179…
You're receiving this email because of your account on gitlab.winehq.org.