Wayland backend errors.

[MrSorcus]

[glfw error 65544]: Wayland: Focusing a window requires user interaction
[glfw error 65544]: Wayland: Clipboard setting not implemented yet
[glfw error 65544]: Wayland: Clipboard getting not implemented yet
[glfw error 65544]: Wayland: Window attention request not implemented yet

kitty in sway

[linkmauve]

The first one will never be fixed, a client is not allowed to steal focus from another, this behaviour is extremely bad for most users, and can be catastrophic when e.g. they are typing a password or other sensitive information.

The second one has been implemented in #358, which probably needs to be refreshed, I can provide review if someone does it.

For the last one, there is no protocol available yet AFAIK, one would need to write one and implement it in some compositors first, if you are interested in that you could head to wayland-protocols, have a look at how they are written, and propose one.

[linkmauve]

Clipboard support has now been merged, see #1353, closing this bug.

[almarklein]

[glfw error 65544]: Wayland: Focusing a window requires user interaction
...

The first one will never be fixed [...]

@linkmauve it looks like that error still occurs on Wayland. In the Python glfw wrapper this means that one cannot create a window on Wayland, because glfw errors are thrown as Python exceptions.

Could you please clarify glfw's approach to this error, so that we can think of an approach to fix this issue in the wrapper? E.g. can glfw (this repo) adopt a change so that the error does not occur, or should we accept that this error occurs and somehow deal with it in pyglfw?

[linkmauve]

I think the best thing to do would be (for GLFW and user programs) to stop trying to steal the focus away from the user, an operation which is (rightly so) not supported in xdg-shell.

As for making the steal focus operation a noop rather than reporting an error, I’m not sure this should be done as it would confuse devs as to why it didn’t do anything. I’m not 100% set on that, for instance if we deprecate this function (and effectively make it a noop on every platform) it would probably be fine to not report an error.

Maybe in the meantime you should log errors by default rather than throwing exceptions, or document that behaviour to your users?

[almarklein]

I think the best thing to do would be (for GLFW and user programs) to stop trying to steal the focus away from the user

It looks like glfw is trying to focus on the window when it is created. The code I'm running, nor pyglfw seem to try to focus on it by themselves. Does that make sense?

Maybe in the meantime you should log errors by default rather than throwing exceptions, or document that behaviour to your users?

That's an interesting thought. Can I infer from this that you consider some errors more like warnings, i.e. a message that the user should see, but does not mean that glfw is in a critical state? Perhaps at some level (at pyglfw?) we should better distinguish between errors and warnings.

[elmindreda]

That's an interesting thought. Can I infer from this that you consider some errors more like warnings, i.e. a message that the user should see, but does not mean that glfw is in a critical state?

None of GLFW's errors mean that GLFW is in a critical state. Barring a segfault, the worst that should happen on error is that the requested operation failed. This includes GLFW_OUT_OF_MEMORY.

[elmindreda]

In the master branch these errors now use GLFW_FEATURE_UNAVAILABLE or GLFW_FEATURE_UNIMPLEMENTED, which should make them easier to reason about and handle.

[FlorianLudwig]

The following workaround makes pyglfw behave like glfw:

import glfw

glfw.ERROR_REPORTING = "warn"

[zoeleu]

For focusing a window error: why can't it just be a warning? Minecraft crashes under GLFW Wayland because of this error.

[theoparis]

For focusing a window error: why can't it just be a warning? Minecraft crashes under GLFW Wayland because of this error.

Why is this closed? This is still breaking minecraft with wayland.
There seems to be a patch here but It'd be nice if this wasn't required along with building glfw from source.