Wayland support

[icefoxen]

Hi, just a question, do you have any intention or plans to support Wayland on Linux? There's a lot of STUFF that needs doing for Wayland and fitting it into a single-header library may not be desirable, so it's pretty reasonable if you aren't going to do it, but I was wondering if you'd given any thought about how it might work with sokol_app.h's existing design.

[floooh]

Hi, there's an incomplete pull request and some discussion here:

#173

I'd be interested in Wayland support, especially if it could one day replace the X11/GLX code, which is a pretty big mess. But I have a feeling there's too many open questions, and IFIR it wasn't really an option to support Wayland alone, but that a X11/GLX fallback would still be needed.

So to be honest, I don't know if it makes sense yet.

Another thought I keep rolling around in my head is to have a special "SDL backend" in sokol_app.h just for Linux. It sounds a bit odd at first (why use sokol_app.h on top of SDL instead of using SDL directly for window/context setup), the reason would be that SDL is the "de-facto" DirectX for Linux, and a lot of work has gone into supporting all minor differences and quirks of different Linux distributions.

[digitalsignalperson]

FYI the GLFW samples from sokol-samples seem to run as native Wayland windows without much effort:

sudo pacman -S glfw  # arch linux
cc cube-glfw.c glfw_glue.c -o cube-glfw -I../../sokol -lGL -ldl -lm -lglfw
./cube-glfw

For me by default this is a Wayland window (default for GLFW and likely will be for SDL3 coming out soon too).

Side note: this doesn't work with the fips build. I see that fips-glfw/CMakeLists.txt is similar to but out of date to fips-glfw/glfw/src/CMakeLists.txt with respect to wayland protocols and stuff, and I'm not familiar enough with cmake and fips to understand how to port it (or can that latter whole CMakeLists just be included so they stay in sync?).

---

Another thought I keep rolling around in my head is to have a special "SDL backend" in sokol_app.h

What if sokol_app.h is modified so that if _SAPP_CUSTOM is defined, then it allows for implementing custom backend functions externally? For example:

#if defined(_SAPP_CUSTOM)
/* user-provided functions */
...
extern void _sapp_custom_toggle_fullscreen();
extern void _sapp_custom_update_cursor(sapp_mouse_cursor cursor, bool shown);
extern void _sapp_custom_set_clipboard_string(const char* str);
extern const char* _sapp_custom_get_clipboard_string();
extern void _sapp_custom_update_window_title();
...
#endif
...

SOKOL_API_IMPL void sapp_toggle_fullscreen(void) {
    #if defined(_SAPP_MACOS)
    _sapp_macos_toggle_fullscreen();
    #elif defined(_SAPP_WIN32)
    _sapp_win32_toggle_fullscreen();
    #elif defined(_SAPP_LINUX)
    _sapp_x11_toggle_fullscreen();
    #elif defined(_SAPP_CUSTOM)
    _sapp_custom_toggle_fullscreen();
    #endif
}

...
}

and then let the user define the implementation functions (some or all as needed).

This would be handy if I you want to use sokol_app.h for all platforms except needing GLFW or SDL or something experimental for a specific platform.

Also that way something like the work in #425 could be maintained in a separate header without needing official support.

---

Edit: see here for a working POC of this idea https://github.com/digitalsignalperson/sokol-custom