[arghwhat]

s/KiCAD needs/KiCAD wants/

As a user of KiCAD, I have not found any need for it to automatically move cursors or windows around (nor do I even remember such behaviour pre-wayland, so it can't have been important), but note that the cursor-warp protocol is coming to allow the former, and window tags are coming to allow things like window placement restoration, which should help where this may benefit UX.

Technical note, OpenGL is for rendering, which is unrelated to presentation. Window managers and display servers have no part in that process. It's the Window System Integration (WSI) if used, such as EGL or Vulkan WSI, and in the old days GLX, that talk to the display server.

Wayland only provides an optional suggestion for when it is a good time for a window to render for good frame pacing, latency and performance without the app having a full proper frame scheduling implementation itself. The issue that tends to crop up is that EGL, a WSI often used with OpenGL in apps not using a toolkit, when specifically told to block and wait for next frame, has been internally implemented to use the optional suggestion which is not provided for invisible windows.

Stuff is being done to solve this, and it doesn't affect applications that do not ask to block on updates (say, firefox), nor applications leaving this up to a toolkit (say, Gtk or Qt) or just a different window system integration than EGL (which is extremely limited on its own anyway).

[vbezhenar]

> As a user of KiCAD, I have not found any need for it to automatically move cursors

Well, the first thing you do with KiCAD is scrolling to zoom in and out, and KiCAD scroll works in a way to jump cursor to the center, so you basically can pan and scroll at the same time. That's default behaviour unless you changed it in the settings, and, obviously, it needs to warp cursor to the center of the window.

[arghwhat]

The way pan-and-scroll works in every other CAD program has been that zooming with the cursor off-center is a panning zoom (zoom centering on the cursor position), without the cursor warping anywhere, so that seems like a reasonable behavior. I do see that the described behaviour can be convenient, but definitely not a deal-breaker in the space.

Maybe I changed the config, can't remember and I must admit that it's been a little while since I had to fire it up.

[ruszki]

I think, you can solve that with keyboard/mouse shortcuts without moving the cursor at all. What’s the reason why they don’t do that?

[jdiff]

You cannot get the level of control out of keyboard shortcuts that you can with fine grained mouse movements. It'd be like trying to play a videogame while controlling camera movement with a controller DPAD/arrow keys.

[ruszki]

I didn’t talk about using keyboard alone…

[jdiff]

You didn't, but if we're introducing the mouse, we haven't dismissed the issues stemming from the lack of pointer warping.

[ruszki]

Why would introducing a mouse interface necessitate pointer warping? There are several millions/billions of apps which utilize mouse and doesn’t need pointer warping.

So the second time, why is it needed in this case, and why it cannot be solved other ways?