Having a const generic for that didn't turn to be a good API.
Also made the C++ side more difficult
(Also renamed buffer_stride to pixel_stride)
Closes#2135
This way the command line can be copied and pasted into a terminal, even
when the USB port differs (for example on macOS). Instead, this now
defaults to a command line that makes espflash prompt, but the added
text explains how to shortcut that.
This is a work-in-progress.
Similar to the S2 Kaluga board, this provides the basic support for
showing pixels on the screen of the S3 Box. There is no support for
touch input yet, or any of the button peripherals. There is also a bug
somewhere that causes the printerdemo_mcu to raise an uncaught
exception. Only a content-reduced version of the printer demo shows on
the screen.
Since rp-pico and rp2040-hal are in the same repo now, that works.
This will prevent warnings when building things with the example
disabled
```
Patch `rp2040-hal v0.6.0 (https://github.com/slint-ui/rp-hal/?branch=dma-0.6#49af1f92)` was not used in the crate graph.
```
crates.io won't let us upload a feature with dots in it:
```
Uploading slint-interpreter v0.3.0 (/home/olivier/slint/internal/interpreter)
error: failed to publish to registry at https://crates.io
Caused by:
the remote server responded with an error: invalid upload request: invalid value: string "compat-0.3.0", expected a valid feature name at line 1 column 2254
```
- rename the mcu-simulator feature to just "simulator" (the mcu is
redundent)
- Don't forward other feature than the simulator from the board support
crate. (i don't want to have to forward all features from all
examples)
- default to the simulator (doesn't compile without any feature
otherwise, leads to error in rust-analyzer)
This way we don't have to add defmt, esp32-println and others as features to corelib and the slint api crate
(which would also expose them as public dependencies),
but instead this can be simply delegated to the Platform trait.
This simplifies the implementation of the pico and STM, as they both
have the same PlatformWindow implementation, and is likely to be the
same for every MCU
