No, not really. Modern APIs usually don't even let you access that kind of information without additional privileges. Some older toolkits have functions that are supposed to do this, but it doesn't work everywhere.
It works fine on Windows and macOS's desktop APIs in 2024. This is a basic "desktop app" expected feature - if you aren't able to implement fully something like AutoHotkey or AppleScript macros, you aren't really a proper desktop platform.
You can implement all those things, just differently now.
Relatedly, now random apps can't record the whole screen. This is a good thing, now they get explicit user permission and go through xdg. I don't know how anyone could be opposed to this - it's objectively more empowering for you, the user.
Yes, it's empowering because your "rights model" is one where you don't have rights. You don't know what applications are using what data, and you also can't stop it. Is that empowering? I think no.
But if you wanna argue Chrome should be able to read all your keyboard inputs whenever it wants be my guest. I can't fathom why people want that type of setup.
Windows' pointer position is available to even the most limited GUI application; it is not protected information. For win32 at least, I am not familiar enough to say that about the newer app packages which are much more locked down, but I would be surprised.
They queried that info based on a specific implementation of a framework. If that framework is implemented under Wayland, then through the Wayland APIs it will only get rudimentary info on mouse position (e.g. only when it’s in focus and the mouse is over it).
App doesn't have to be in focus. It receives pointer events over its own surfaces (plus in some additional cases like drags and grabs). It doesn't receive any information about pointer position otherwise, nor its global coordinates (at least not without extra protocols).
Is it possible that one could write essentially a transparent app, which is always in focus and just passes click events through the transparent layer?
You can write a transparent app, but its the compositor that decides whether it's in focus and your app will either pass both hovers and clicks to the window behind (not staying in focus for long and not getting any pointer events even when it still is), or it will consume them all.
Why? I want to have some applications that can always see the mouse cursor like, xeyes. Because that allows me to implement a better customized desktop environment.
Then give that piece of code extra-special permissions. As I’ve said in another comment, the days where you downloaded your software from the sunsite or tsx11.ai.mit.edu FTP servers and could be confident that it and all its dependencies were trustworthy are unfortunately gone for a very long time.
"stdlib" was shorthand for "the standard library of a given language" and it came across poorly.
I did a quick google before I asked you that question, and it looks like wayland is one of the few exceptions to completely exposing current cursor position. Most "stdlibs" do expose it.
I will not refrain, you're the only one confused by it.
Just google it. You are incorrect and you're not pumped about it, I get it. The horse is fully beat to death. If you want to discuss further, my responses will probably just be lmgtfy links.
I find their point pedantic, but I tend to think it is correct. The "standard library" of a language is the library that comes with the language itself, usually across all platforms, and that rarely contains anything UI-wise beyond the very basics (e.g. text/terminal I/O like printing and reading lines).
I do agree that probably no-one was confused, though.
It's clearly you who's confusing "standard library" with "UI toolkit". Some standard libraries come with a toolkit, like Java, but that's an exception rather than rule.
Not that it makes a huge difference in the discussion, but if you want to be smug about it then at least make sure you're right first.
No he didn't. Java is quite possibly the only mainstream language that provides a GUI toolkit in its standard library.
It's an exception, not the rule. Even Python, well known for its batteries-included std, do not provide this magical get_cursor_pos() function that you insist is found in stdlibs.
