> What is relevant is that, presumably, Windows and Mac and X11 users of Kicad use this functionality.

Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor. Windows and Mac and X11 users praise KiCAD for having a nice UX. You can definitely implement features like infinite panning in today's Wayland compositors, you just can't do it by absolutely setting the cursor position.

> The onus is on the Wayland team to justify the decision to take away a feature currently in use, not on the user base to justify switching to another system.

This is a genuinely cancerous mentality. When you design a new API, "the old API had a function that does this" is not a valid justification. If you can't find another justification for why the function should exist, it means that it shouldn't. That's what designing from first principle looks like. I have actual reasons why the old functionality (getting/setting the absolute cursor position) is not an API that I want, too, but that's not even the point. API functionality should be able to stand on its own and justify itself. If you can't start on a completely clean slate, why even bother trying to design a new API in the first place?

It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum. It is a useful API primitive, because it can be used to implement other useful things, and a ubiquitous API primitive, but that doesn't mean it's a good API primitive. On the contrary, most of these desktop systems were designed a long time ago, and now modern OSes are actually having to come up with ways to carefully limit a lot of these sorts of very powerful legacy APIs because they can lead to security and privacy issues. As an end user and computer owner, I don't want random applications running on my desktop to be able to get or set the absolute cursor position on screen, especially when the window is not focused. And if I don't want that, then the next obvious question is, does something like KiCAD truly need that? Of course not. Applications need primitives that can implement the controls and UI that they want, but you don't just get to decide what those primitives are, as an application. As an application, you get to deal with the primitives that you're given, because by definition, that's literally the job of an application developer. And when those primitives prove insufficient to implement some UI, then we can discuss how to fix it, but the answer isn't "this old API just let me get/set the global cursor position so can I have that?" And if you don't like some system you don't have to support it. But Apple is a complete and utter dickhole to application developers, requiring all kinds of dumb signing bullshit and pushing users to huge proprietary APIs like Metal, and yet open source projects are happy to sink plenty of developer hours (and often money) into it anyways, even though its desktop marketshare is only somewhat more impressive than Linux anyway. So forgive me if I don't shed a tear because it required a bit more work to do something in Wayland than it did elsewhere.

And yes, I know: you can come up with an application that really truly actually does need this. There are a handful, like automation software, or a remote desktop server. Actually though, pretty much all of the modern Wayland desktops support being able to get or set the absolute cursor position for that use case, it's just that it will usually require a permission prompt, at least the first time you use it. (There are some exceptions. wlroots/SwayWM doesn't require a permission prompt for this, the functionality is exposed as long as applications are not sandboxed.)

Application developers have developed this sense of ownership over the desktop that has become very annoying. No. I want my desktop environment to act as the owner of my desktop, the same way I want my window manager to control the management and positioning of my windows. Your applications just get to live in that world, the way that web pages get to live in a web browser.

Love it or don't, Wayland exposing higher level APIs for things that used to be implemented by application developers using lower level APIs is a step in the right direction for higher quality desktops and for user's control over their own desktops.

> Windows and Mac and X11 users do not praise KiCAD for its ability to absolutely position the cursor.

What does praising have to do with it? After all, I use my television remote mainly to control the volume, but I have never praised the ability to control the volume.

> When you design a new API, "the old API had a function that does this" is not a valid justification.

That is not the justification I, and others, gave; it's essentially a strawman that pops up in every single Wayland conversation.

The justification is "Windows, Mac and X11 allow this feature."

At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.

> It doesn't matter if Windows, macOS, X11, Haiku, BeOS, SkyOS and TempleOS all provide this functionality, that's not a good justification, that is just argumentum ad populum.

Well ... yes? What's wrong with that? What's wrong with the argument "All the competitors provide this"?

> At that point, the onus is on the Wayland devs to justify why they are removing a feature found in every mainstream desktop OS.

You actually haven't come up with any good reason to justify this, you've just repeated it as fact for some reason. And what's weird is, there's no point in doing this. Like, I can understand doing this maybe earlier, when there was possibly a question if Wayland would succeed; at that point, the proponents, designeds and developers of Wayland and Wayland software had something to prove.

But guess what? It's over. There's no more fight for Wayland to prove itself. Wayland is, for now, here to stay. We are done with that part of things. Nothing will literally stop someone from using X.Org, anymore than you are stopped from doing anything with your own computer, but the Linux world is largely moving on. Application developers are largely moving on. Toolkit developers are largely moving on. Desktop environments are largely moving on. Distributions are largely moving on. And nobody in this process is losing immense sleep over wxWidgets or KiCAD not having complete parity because it's not a big deal. We genuinely have more important things to worry about.

So framing this fight with whatever basis you personally feel appropriate is a waste of my time and a waste of your time. If your best justification is 'everyone else was doing it in 1999', you can pipe it to /dev/null and save us all some time. We don't care.

So no, the onus is absolutely on you to justify this. You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.

All modern desktop systems supported silently querying and setting the absolute position of the cursor... Before Wayland. Wayland became a modern desktop system that doesn't, so now not all modern desktop systems support that. And if a commercial vendor ever decides to design a new desktop system from scratch, you can bet all of the hairs on your ass it will have nearly the exact same limitations.

> You can't decide where the onus belongs because you're literally not in a position to do so, the Wayland project, for all of its faults, has largely succeeded and doesn't need to justify itself in this fashion anymore.

TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.

Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.

There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.

You want security on your desktop? You get it. I want KiCAD on mine? I get it.

What, specifically, is the reason that you feel so strongly that only one option must be enforced?

I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?

> TBH, "need" doesn't come into it. It can't. There's no justification for not maintaining feature parity with current competitors.

Firstly, again, choosing your own premise here isn't going to do you or me any good. I'm happy to waste my time because for some fucked up reason I actually enjoy participating in threads like these, but unless you also do, I have to warn you that this is simply a waste of time as I'm not interested in this premise and it won't do any good to convince any Wayland proponents. To put it bluntly, your opinion on where this argument starts is really not material because nobody really asked.

Secondly, this premise is terrible anyways. First, it starts with the assumption that there's no justification for why not to provide the ability to position the cursor directly, which isn't true, and you seem to recognize that when you mention "security" later on (though that is certainly not the only reason.) And anyway, this premise pushes the idea that you have to justify not introducing features when designing an API, which is just silly. Wayland started with a completely clean slate, and there are plenty of things that X11 and Win32 can do that Wayland can't do, but I don't see anyone complaining about the lack of X11 colormaps or the ability to run without compositing. This idea applies much better when it comes to removing features: you would need justification to remove a feature that already exists. Wayland doesn't have this feature (absolutely positioning the pointer), so it has the opposite: it would need to justify adding the feature. But when Wayland developers get a feature request, they don't just blindly add the feature. They dig deeper into what applications really want and try to figure out the best primitive that allows the desktop and application to work together. Just letting applications position the cursor absolutely is pretty inelastic; you can develop primitives that are maybe a bit less powerful for applications, but are much more powerful for the desktop as a whole.

The reason I haven't been talking about justifications for why there isn't an explicit API to set the cursor position is because I think that would mislead someone into thinking that's a worthwhile thing to debate about when in reality it's not. If anyone thinks this is actually a good idea for an API in Wayland they can try to add it, you don't have to be anyone special to do it. In practice though I really strongly believe that if someone made an earnest effort to do so they would wind up changing their mind anyways after actually understanding the entire scope of what it entails in the frame of how Wayland works.

> Further, users don't care about your purity tests, they care about being able to run applications, like KiCAD.

> There is no justification in the world for "It's a feature to have applications that break only on our system". After all, with this specific feature, there's lots of ways to allow it without compromising security.

> You want security on your desktop? You get it. I want KiCAD on mine? I get it.

> What, specifically, is the reason that you feel so strongly that only one option must be enforced?

> I'm not being facetious, I'm genuinely curious here: how does enforcing "no pointer warping" for you and relaxing it for me, hurt you?

I've been very carefully to be specific in hopefully every post I've made so far: what Wayland lacks is the ability to absolutely position the mouse cursor. It does not lack the ability to do mouse wrapping, for example, or constrain the pointer, or any of that stuff, it just can't be done the way KiCAD currently does it for existing desktop systems. These things work in existing Wayland software. That's actually the point of my first post in this thread a few levels up where I point out that KiCAD developers have made the messaging confusing, making it sound like these problems are inherent to Wayland when they're usually not. I stand by this.

I also claim that I don't really find it surprising that KiCAD developers are not excited to have to deal with Wayland things that basically don't exist in other desktops. I personally think they should prefer XWayland for now and continue leaning on wxWidgets to improve Wayland support over time. I fully believe wxWidgets can evolve to add higher level abstractions where lower level ones fail on Wayland, basically solving the problem for more than just KiCAD. GTK and Qt themselves have largely done this already.

And also, I don't feel that only one option should be enforced. In fact I don't even care if people only use Wayland, I'd be happy to see Arcan succeed, or people using Wayback, or even X11Libre, whatever. Moreover if someone wants to propose a Wayland protocol that allows querying and setting the pointer position, they can do that. I am actually not overall a fan of how monolithic the Linux/free software desktop has become. Even though I prefer systemd, for example, I generally dislike the way it took over and how everything now has very systemd-specific logic all over it. That's part of why I like Wayland, everyone sees it as being hugely opinionated, but actually it's not, it's basically a very minimal protocol that can be extended infinitely to do whatever you want, and each compositor gets to make it's own choices. As an application developer, this does cause you some headaches especially during the transition as you have to cope with some fragmentation especially if you do a lot of lower-level (in terms of desktop) stuff. This does not imply though, that applications should do a bunch of Wayland specific things, instead, I believe they should push features like pointer wrapping to a higher level to the point where the implementation can be done the old-school way or using Wayland protocols. (Some applications were basically already here and just needed an implementation.)

The thing is though, even though all of the Wayland compositors are totally free to implement whatever functionality they see fit, and they absolutely do, btw, they still don't implement an exact match for the API that X11 has here. I think all of them actually agree that the old API isn't particularly good. Even if they wanted to implement it such that applications like KiCAD could just ignore all of this, they literally can't: the old X11 APIs (i.e. XWarpPointer) are not designed for multiple seat, multiple cursor systems, even though X11 was extended to support many cursors a long time ago. The Wayland API is just simply going to require more work to implement versus systems that have legacy APIs that operate on a single global cursor. And simply treating an arbitrary choice for which seat/cursor to use is just not a very compelling decision.

FWIW, KiCAD does run on Wayland natively, but until it runs with full parity, it's probably going to be better ran under XWayland instead. And unless you desperately want something Wayland offers that X11 doesn't ("perfect" frames, more seamless high DPI rendering, better handling of VFR, color management) it just doesn't make sense to sweat over some applications still needing to fall back. As far as I'm concerned the XWayland fallback should continue to exist long into the future, ideally until it's so old that the applications that still need it are better ran under an emulation environment. (I'm not sure if that's even in my lifetime though.)

If a commercial vendor went out and tried to make a next-generation desktop system, without the baggage of any existing systems, I would be willing to bet a fortune they would come to agree on Wayland's limitations for unprivileged applications. Maybe they, together, marginally improve desktop security and privacy, but most importantly, I think that the Wayland way leads to better software, that makes less assumptions and needs less heuristics. This isn't about ideological purity, at the end of the day. It's about trying to improve the status quo. Improving the status quo is fucking hard.