As I was implementing the Wayland backend, I learned that there are two protocols of interest:
- The Shell core protocol
wl_shell.
- The extension XDG-Shell protocol
xdg_shell.
I was implementing the first, but it seems that the second is the one of most interest, since it's provided by the compositor as a way to make the surface behave like a window controlled by the compositor. However, the core protocol might be still useful, particularly for non-game applications.
For this reason, the backend for the core protocol will remain, and I will add the XDG-Shell protocol when the first stable release happens.
This means that for the Wayland backend, there will be an option for what kind of window will be created. Possibly with this design:
swfw_hint_wayland_window_type(&swfw_ctx, SWFW_WAYLAND_SURFACE); /* Uses the core protocol */
swfw_hint_wayland_window_type(&swfw_ctx, SWFW_WAYLAND_WINDOW); /* Uses the extension XDG protocol */
status = swfw_make_window(&swfw_ctx, &swfw_win);
I will wait the stable release of the XDG protocol to implement these hints and the XDG-Shell backend. Currently, only the first option will be available.
As I was implementing the Wayland backend, I learned that there are two protocols of interest:
wl_shell.xdg_shell.I was implementing the first, but it seems that the second is the one of most interest, since it's provided by the compositor as a way to make the surface behave like a window controlled by the compositor. However, the core protocol might be still useful, particularly for non-game applications.
For this reason, the backend for the core protocol will remain, and I will add the XDG-Shell protocol when the first stable release happens.
This means that for the Wayland backend, there will be an option for what kind of window will be created. Possibly with this design:
I will wait the stable release of the XDG protocol to implement these hints and the XDG-Shell backend. Currently, only the first option will be available.