One of my design goals for gneiss was for it to be standalone. Early commits show the initial work being codegen stuff to build a valid .pbw “from scratch”, because that’s what interested me. I don’t want to shell out to the python tools on user machines - though I recognize that it’s perfectly sensible to do so.
Nice, I didn’t look too deeply into your code so it seems like I just missed it. So you generate all of your own resources into the custom Pebble formats?
I chose to declare resources in Cargo.toml instead of another file, which means cargo has full knowledge of what every resource is at build time. The constants it generates for you are Type-aware wrappers, pub struct ImageKey(pub NonZeroU32); pub struct RawBytesKey(pub NonZeroU32);. The constructors for the runtime resources take these typed keys as their args, rather than the plain u32. I’m quite pleased with how it’s shaping up, but it does mean that gneiss’ resources don’t maintain 1:1 Parity with how the C SDK does them.
Feel free to Lift my alloc impl wholesale! I’m pretty sure it’s optimal for the Align>4 case, and for Align<=4 it’s just calling through to malloc directly. It costs size + align bytes per overaligned alloc and stuffs the base pointer into that padding, so the cost is less painful for Vec<u64> that it would be for Box<fat pointer with Align 8>, for instance.
… littered with generics […] massive increases the code size as soon as someone uses two different window layouts.
I’ve gone for a very different way of handling UI lifetimes - Windows own their content, so it must be live while the window is, no refcounting. It has produced very generic-y code (which I’m used to, I work with atsamd in my dayjob), Though I reckon I can mitigate most of the monomorphisation cost by type-erasing the internals where possible. I’ve already done that for the Click handlers and turned ~1KiB per window type into ~1KiB once for all windows, if any window subscribes the handlers. I’m going to keep pushing it down as I refine stuff.
All that to say. I don’t find the idea of dropping what I’m doing to work on a similar but different approach to the same problem all that appealing, I’m going to keep working on gneiss. I’m happy to rename my cargo-pebble to cargo-gneiss to avoid name clashing, since mine is very much the gneiss build tool - not generic. I hope exchange of ideas can make both of our projects better.
(on that note, I’m pretty sure your GContext can live too long and escape the renderer - it probably shouldn’t be copy?)