This MR tries to implement the SetIMECompositionRect user driver function and partially the WINE_IME_POST_UPDATE message call. It requires support for zwp_text_input_v3 from the compositor. It supports submitting committed text to the win32 side and notifying the compositor about the area of the text cursor rectangle.
This doesn't add support for embedded pre-edit because I couldn't immediately get it to appear. Either I did something incorrect, or it has something to do with Wayland. On X11, the pre-edit appears completely separated to the application window and doesn't move with it, which doesn't seem to be compatible with Wayland.
If Windows has the surrounding text feature, it does not seem possible to support it here with the provided interface.
The IME is always enabled on the focused surface, like on X11. If Windows has a facility that applications can use to say that it does or does not accept text entry at certain parts of the UI, it does not seem possible to support it here with the provided interface.
--
v7: winewayland: Post IME update for preedit text.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7241
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v2: windowscodecs: Implement CreateQueryWriter().
windowscodecs/metadata: Support creating query handlers over bare metadata handlers.
windowscodecs/metadata: Handle empty items in queries.
windowscodecs/metadata: Split up query parsing into helpers according to the query grammar.
windowscodecs/tests: Add some tests for the query reader container format.
windowscodecs/tests: Add some tests for CreateQueryWriterFromReader().
windowscodecs/tests: Add query reader tests for live block reader updates.
windowscodecs/tests: Add some tests for CreateQueryWriter().
windowscodecs/metadata: Share implementation between query reader and writer objects.
windowscodecs/tests: Add some query tests with the Unknown reader.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7329
On Thu Feb 13 16:48:27 2025 +0000, Brian Wright wrote:
> @rbernon On the client side, if you wanted to know why the log produces
> the values it has or had advice on code changes, the relevant file seems
> to be
> [yabridge/src/wine-host/editor.cpp](https://github.com/robbert-vdh/yabridge/…
> and a few routines responsible for coords and mouse handling that might
> be indirectly showing up in the bug report log include
> **is_cursor_in_wine_window** (line 1442),
> **get_current_pointer_position** (line 953), **fix_local_coordinates**
> (line 785), and `case XCB_CONFIGURE_NOTIFY` (line 552)
> I can attach to Wine and/or yabridge in a debugger, but I wouldn't have
> advice on what to change since I don't know how the handle relationships
> should look in order to find out which routine is producing incorrect
> coordinate offsets. If you want me to try anyway, I can put it in the
> queue of all the other stuff I forget to do once the workday is over.
> Thanks to you and @robbert-vdh for maintaining two phenomenal tools.
I updated the bug tracker again.
In REAPER, the window tree looks a bit like this:
```text
host_window_reparent parent 402, window 200192 (604,402)-(1516,1110)
host_window_reparent parent 200192, window 200193 (0,0)-(912,708) root_coords 1
host_window_reparent parent 200193, window 1600130 (0,0)-(912,708) root_coords 1
host_window_reparent parent 1600130, window 16012db (0,0)-(644,659) root_coords 1
host_window_reparent parent 16012db, window 2200000 (0,0)-(805,460) root_coords 1
host_window_reparent parent 2200000, window 2000003 (0,0)-(1920,1200) root_coords 0
```
I think 402, 200192, and 200193 are from REAPER and the rest from yabridge.
One detail I noticed is that window 2000003 gets the initial click event from yabridge and sends the correct value to **cursor:map_event_coords**. I don't know the structure of event->window, but there is something in [**host_window_configure_child**](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/winex11.drv/window.c#L229) that messes with coordinate offsets.
Is is possible that **map_event_coords** should check the value of `root_coords` and provide `(pt->x, pt->y)` when this is 0?
I'll keep picking at things and see if there's more to find.
-----
Alternatively, a flag/argument solution would get DAW users back in action.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_94623
This MR tries to implement the SetIMECompositionRect user driver function and partially the WINE_IME_POST_UPDATE message call. It requires support for zwp_text_input_v3 from the compositor. It supports submitting committed text to the win32 side and notifying the compositor about the area of the text cursor rectangle.
This doesn't add support for embedded pre-edit because I couldn't immediately get it to appear. Either I did something incorrect, or it has something to do with Wayland. On X11, the pre-edit appears completely separated to the application window and doesn't move with it, which doesn't seem to be compatible with Wayland.
If Windows has the surrounding text feature, it does not seem possible to support it here with the provided interface.
The IME is always enabled on the focused surface, like on X11. If Windows has a facility that applications can use to say that it does or does not accept text entry at certain parts of the UI, it does not seem possible to support it here with the provided interface.
--
v6: winewayland: Post IME update for preedit text.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7241
This MR tries to implement the SetIMECompositionRect user driver function and partially the WINE_IME_POST_UPDATE message call. It requires support for zwp_text_input_v3 from the compositor. It supports submitting committed text to the win32 side and notifying the compositor about the area of the text cursor rectangle.
This doesn't add support for embedded pre-edit because I couldn't immediately get it to appear. Either I did something incorrect, or it has something to do with Wayland. On X11, the pre-edit appears completely separated to the application window and doesn't move with it, which doesn't seem to be compatible with Wayland.
If Windows has the surrounding text feature, it does not seem possible to support it here with the provided interface.
The IME is always enabled on the focused surface, like on X11. If Windows has a facility that applications can use to say that it does or does not accept text entry at certain parts of the UI, it does not seem possible to support it here with the provided interface.
--
v5: winewayland: Post IME update for preedit text.
winewayland: Implement SetIMECompositionRect.
winewayland: Post IME update for committed text.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7241
This allows using one single wineprefix, one wineserver and one single wine executable for running both arm and arm64 executables.
This setup actually has worked earlier; Ubuntu 22.04 packages Wine 6.0, where the wine32 + wine64 packages together end up working this way. However, since Wine 6.0, a couple of refactorings has broken this setup along the way; reinstate this way of working.
The new wow64 mode probably won't work on arm, as it's not easily possible to switch between 32 and 64 bit execution mode within a process, as far as I know, but the old wow64 mode is still a great convenience - especially considering distro-packaged use for users who aren't familiar with the particular quirks on this architecture.
--
v3: server: Include ARMNT as one of the supported architectures on aarch64
ntdll: Allow running arm/aarch64 in (old) wow64 mode
https://gitlab.winehq.org/wine/wine/-/merge_requests/7204
This MR adds clipboard support to the winewayland driver by using the wlr-data-control-unstable-v1 protocol. Note that this protocol was recently merged into wayland-protocols as ext-data-control-v1, but it's not yet widely supported, so I preferred to use the wlr version for now.
This MR has many similarities to https://gitlab.winehq.org/wine/wine/-/merge_requests/7236, but due to the unconstrained nature of wlr-data-control-unstable-v1 the implementation is simpler and more robust. It can neatly fit into the existing Wine clipboard design (single proxy window in the desktop process) without requiring any event forwarding etc.
Since wlr-data-control-unstable-v1/ext-data-control-v1 is considered privileged, it may not be available in all situations, e.g., in sandboxes, and there are also a couple of compositors that may not implement it at all. It is therefore useful to have a simple fallback using the core wl_data_device interface. This fallback is not part of this MR, but I have pushed a WIP implementation based on this MR at: https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-copy-paste-data-… (note: only the win32 -> wayland direction implemented at the moment). The new fallback approach is different from https://gitlab.winehq.org/wine/wine/-/merge_requests/7236 in that when using wl_data_device it creates per-process clipboard windows instead of forwarding messages from the desktop clipboard window. This allows it to work within the design of this MR with minimal changes and maximum code reuse.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/7336