Non-standard window under Wayland and other questions

I cloned the current github glfw and build it with -DGLFW_BUILD_WAYLAND=ON -DGLFW_BUILD_X11=OFF, just to be sure that it’s really running Wayland code (and that none of my code interferes). Then I ran the examples/triangle-opengl example.

I get a very bare looking window without a close button. Can this be fixed somehow ? It’s somewhat of a show-stopper for me.


Other questions

  • I learned that glfw with Wayland uses EGL, but when I query glfwGetWindowAttrib( window, GLFW_CONTEXT_CREATION_API)) after window creation I get GLFW_NATIVE_CONTEXT_API. How can that be ?
  • When I move the mouse cursor along the window edges of examples/triangle-opengl, I get a lot of Error: Wayland: Standard cursor shape unavailable complaints. Why is that so ?
  • I ran tests/window to toy around with the “decorated” setting. I noticed that the opacity slider is not working under Wayland. Is this expected ?

This is the GFWL implementation of window decorations on Wayland. The border can be used to move/resize and with right click menu close.

For your other questions:

  1. If you didn’t set the GLFW_CONTEXT_CREATION_API the value will be the default, which is GLFW_NATIVE_CONTEXT_API. In the case of Wayland this means that the native EGL api will be used.
  2. I also get this, I am not sure why but it’s due to the wayland cursor theme not having the “e-resize” and “s-resize” cursors. This might be worth opening a bug about.
  3. Wayland does not support setting the window opacity, but I think you can set framebuffer transparency if the compositor supports it.

I figured my post was lost in the spam bucket, so I made a duplicate issue in github. Sorry for that.

Should I put up more issues into github or just continue here ?

If I were to write a user app, I couldn’t ship these GLFW decorations in good conscience in the current form (personal opinion of course). I guess for some reason GNOME can’t put its usual window decorations around wayland windows, though it can for X11 windows. But then also non-GLFW wayland code ought to have the same problem ? Do you know, if and how this is planned to be resolved (I don’t mean by glfw only) ?

The reason is apparently that GNOME doesn’t want to do it (XDG-Decoration support (#217) · Issues · GNOME / mutter · GitLab). I looked into SDL, and they use a library called libdecor to get something borderline acceptable on the screen including a window shadow. It looks bad, but at least there is some basic usability. (For some reason I can’t upload screenshots unfortunately)

As to question 1. Since there is a distinct GLFW_EGL_CONTEXT_API I would have expected this to be returned a) because it’s there and b) because what’s the advantage of GLFW_NATIVE_CONTEXT_API, when under different circumstances on the same machine it means something different. If I were to know it’s EGL, I could then attempt EGL code paths or so my reasoning would go.

This is a forum for help in using GLFW. If you have an issue with the implementation of GLFW then Github is the place to post those issues. This thread is somewhat in between, so I can’t say for sure which you will find more helpful.

This is a consequence of the Wayland communities decisions, I couldn’t ship Wayland in good conscience in the current form (personal opinion of course). I agree with SDL author Ryan Gordon’s comments on the thread you linked to that implementing server side decorations is the way to go rather than letting apps deal with it.

An alternative is to create an undecorated window and add your own window decorations via a GUI like Dear ImGui or Nuklear. This way your app can have consistent look and feel across OSs (perhaps optionally outside Wayland since some users prefer default OS style).

RE: glfwGetWindowAttrib( window, GLFW_CONTEXT_CREATION_API)) The value returned is the value set - which is the default of GLFW_NATIVE_CONTEXT_API. I think your use case is valid, but I think this should be implemented as a different function glfwGetWindowContextCreationAPI( window ) which would return the actual API used rather than the window creation hint attribute set. This can be worked around at the moment by using the native API to query for available contexts per API, and checking if those are valid.

Yeah, I am with you on the wayland situation, but I am not sure how much weight SDL and GLFW have when it comes to getting a sane solution or everybody. It could become a problem that’s never solved properly.

I looked at the wayland code in the GLFW codebase and noticed it was written in 2014 by the same guy that also wrote libdecor (presumably for SDL) five years later in 2019. Is he still active on the GLFW wayland code ? libdecor is extremely barebones, yet at least somewhat usable.

There are several advantages with the SDL method, not least, that there is a shadow around the window, which I believe makes resizing easier. With the glfw window it’s very hard to grab the corner properly for a two dimension resize. And of course there are some window controls!

I can’t upload images for some reason, so I will need to use an external picture storage. This will surely place me in the SPAM folder again, so I will put the screenshot into a separate reply.


It looks like libdecor client-side support has a PR already (and it’s marked as Urgent by elmindreda).

That’s encouraging :+1:

I somehow missed this when searching the issues & PRs, probably because the title of both doesn’t include Wayland.