On Tue Oct 22 16:00:21 2024 +0000, Rémi Bernon wrote:
Hmm okay, but still, making a dedicated request and flag feels a bit too much like a ad-hoc solution to workaround an incorrect design. I know fixing the design would potentially require more changes, but I think it's the right thing to do. Adding ad-hoc workarounds will just make it more difficult to fix it later. For instance it's described in https://devblogs.microsoft.com/oldnewthing/20111219-00/?p=8863 that WM_MOUSEMOVE are generated on-demand, probably this is the case where it happens.
But it stems from the fact that we don't have a single monolithic win32u kernel which has all in place, the messaging handling is split between the client Unix part and the server. That is the case for virtually any non-trivial window configuration operation: some parts are performed through server, messages to be sent are generated mostly on the client. Do you have some specific considerations in mind why this cursor update is a hack while the rest of set_window_pos isn't, or what kind of redesign that could be?