Thanks for the proposal. The current version is a good starting point, but I think it's more complex than needed, since it's designed around X11 requirements that are not necessary for Wayland. The main one is that Wayland (like win32) can set the various icon variants independently, whereas X11/_NET_WM_ICON requires always setting up the complete set of icons.
Here are some suggestions about how we can move forward:
1. Create a `wayland_surface_set_icon(struct wayland_surface *, UINT type, HICON icon)` function in wayland_surface.c which will be responsible for extracting the icon data to a SHM buffer and setting the xdg icon.
Concerning the SHM buffer creation from icons, we already have a function that does exactly this: `create_color_cursor_buffer` in wayland_pointer.c. We can move the function to wayland_surface.c under a better name, e.g., wayland_shm_buffer_from_color_bitmaps and use it in both places. This removes the need for the `get_bitmap_argb` etc.
2. In `WAYLAND_SetWindowIcon` we can call `wayland_surface_set_icon()` with just the required type and icon passed in. All the complexity of getting/setting the icon of a different type is not needed here.
3. Introduce a `HICON get_window_icon(HWND hwnd, UINT type)` helper which will perform the search sequence for the type, similar to what `fetch_icon_data` does internally in the current proposal. We can use that function to get the icon and pass it to `wayland_surface_set_icon()` in WindowPosChanged. Like in winex11, some care is needed to ensure we don't call the `get_window_icon()` helper with the window data lock held (but note that we need the lock when accessing `data->wayland_surface`).