"sapp" libraries design discussion

[icefoxen]

Looks like the sapp-* libraries are direct c2rust translations of the sokol_app

Easy things to do would be:

• Refactor out common types, definitions, etc. into their own crate
• Make a single crate that selects the right backend based on the compilation target, so you don't need sapp-linux, sapp-windows, etc and can just use sapp.
• Rustify a few of the types -- turn big lists of consts into enums, for instance, maybe replace a bunch of the C numbers with Rust equivalents

I'd like to help with doing this, but a) I can't promise anything, and b) you're the one who would be maintaining the result. So, if you think this is useful I might make some PR's, but I don't want to redesign things in a way that you don't like.

[not-fl3]

Hi! Nice to see you there! :)

Short disclaimer: I would like to make sapp usable outside of miniquad and am fine with library redesign towards that goal. But keeping it simple and straightforward for miniquad usecase is a priority - I dont really want to build too general purpose and good-for-everyting library here.

Make a single crate that selects the right backend based on the compilation target, so you don't need sapp-linux, sapp-windows, etc and can just use sapp.

Let me describe why sokol-app-sys was splitted into 3(and later even more) crates:

• cargo does not support [target.'cfg(windows)'.build-dependencies] and resolve #[cfg(target=``)] in build.rs as a host platform, not the target platform. So its not possible to have completely different set of build dependencies.

• sapp-wasm, sapp-linux and sapp-windows are actually pretty different things: sapp-wasm is writen from scratch mostly in JS with rust bindings sapp-windows is sokol-app C bindings. sapp-linux is cleaned up c2rust code

Some inputs and thoughts to consider in the crate design:

• sapp-wayland will be implemented from scratch - there is now wayland support in sokol.
• apparently the best way to deal with wayland is through C bindings to libwayland-client. I am not sure yet, but it looks that libwayland-client is inevitable to get EGL context. Need more research, my wayland knowledge are very shallow.
• sapp_windows could be rewriten in pure rust. windows.h is heavy and hard for both c2rust and bindgen, but I am sure that this can be workarounded.
• Android/Macos/IOS are unknown lands for me right now, probably some native bindgins will be required. And maybe some Java or ObjectiveC?

The ideas I have about the future of sapp design right now:

• rewrite everything in rust and make one small and nice pure rust crate. But I am not sure that it is possible for some of the platforms.

• make one meta crate with common datatypes and depend on platform specific subcrates to workaround cargo's build.rs issue

• if cc-rs is the only extra dependencie for all the platforms - I can live with that, its not that heavy. If no more build dependencies will appear for mobiles - we can move everything back to one crate.

[dasifefe]

Hi, as a beginner in Rust, and long time C programmer, I am loving this library. I like the goals and non-goals you have settled.

MacOS backend

I don't have a MacOS, but I know for sure it's annoying to support. You won't need Objective-C, since you can use the Objective-C runtime API, which is pure C. So, because it is pure C, it makes easier to integrate, but the API is VERY verbose (reference: 1, 2, 3).

Wayland backend

I actually was working on my own windowing library, and I have a backend with a lot of Wayland implementation. I am not sure if it compiles nowadays (I might have done some refactoring and stopped in the middle), but the logic is there. And yes, with Wayland, hardware acceleration is done with EGL. You can also just go without hardware acceleration. I have in my implementation EGL support, keyboard support, pointer/mouse support, unfinished tablet support. Wayland is an annoying library too, from the C perspective, because of some protocols not being core. The user experience feels much smoother than X11, though.

I will send you this Wayland implementation later.

[not-fl3]

I believe going with sokol-app and linking with C-api of sokol-app is the less painfull way to deal with MacOs. But, yeah, I need a mac to test. Going to try virtual mac soon, maybe virtual mac will be enough at least for MacOS, without iOS.

[icefoxen]

Also for reference it seems like the closest thing in pure Rust to libwayland-client is smithay-client-toolkit, I think. I'm still learning myself. The same project maintains bindings to libwayland-client as well. However, it looks like your intention so far is to have literally zero dependencies beyond cc, which is a little crazy and also awesome.