On Tue Oct 22 16:05:42 2024 +0000, Paul Gofman wrote:
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?
Also, currently the whole handling of the mouse input is performed by sending hardware messages from the client now. I know you have thoughts about moving all of that to server, but even then I don't immediately see how that could help this case. Here it is induced by window move and the place to do it is stipulated by the other messages performed on client. Do you have in mind this whole system (including set_window_pos, various message handling on repaint) to be moved to the server somehow?