The options in sixtyfps-viewer --help used to look like this:
```
OPTIONS:
--backend <backend> The rendering backend [default: ]
-I <include path for other .60 files>...
--load-data <load data file> Load properties from a json file ('-' for stdin)
--save-data <save data file> Store properties values in a json file at exit ('-' for stdout)
--style <style name> The style name ('native', 'fluent', or 'ugly') [default: ]
```
This patch removes the useless "[default: ]" part. These are options,
so even without this text it should be very obvious that the `--style`
and the `--backend` parameters are indeed optional.
Remove the `application` infix from `register_application_font`, to
reduce the changes that it might be interpreted to be a function that
also changes the default font in all text elements.
This allows creating multiple windows for example, and it will allow for
showing windows in those tests that require a mapped window.
As a bonus, the run() function on generated components is not consuming
anymore.
We need to embed resources in wasm builds. Unfortunately we can't detect
that we're called by say wasm-pack and "TARGET"/"HOST" only works inside
build.rs. So instead, to keep things simple, this change always embeds
the image resources when targeting Rust.
The `SIXTYFPS_EMBED_RESOURCES` environment variable can be used to
override this anywhere for any language.
Fixes#130
Move the layout constraint tracker into the window where we can apply
the constraints right before drawing, instead of doing that from within
the event loop. This allows to remove the component parameter from the
run function.
This will allow the online editor to load imports from URL asynchroniously later
Since currently the compiler is only working on a single thread, and that we
never await on a future that could block, it is allowed to use the spin_on executor
Currently the Qt backend still redirect everything to the GL backend,
but the goal is to use QPainter and QWindow
This also adds a "default" backend, whose goal is to select the proper
backend at compile time
Instead, pass a reference to the root item when mapping the window,
at which point we can downcast to the new Window item. If we have one,
then we'll read its width/height (for initial values) and install
bindings to keep them up-to-date.
This allows specifying additional component locations. It works for
simple structs, but not yet for more complex types due to a bug yet to
be fixed :-)
Don't require the callers to hold on to the source code string until an
eventual diagnostics code path is hit. Instead it turns out it's
simpler to let the parser consume the source code as string, where
internally after tokenizing it can be moved into the diagnostics and
from there into the code map if needed.
There are a few places where we now clone the source code, but that's
only in cases where we also extract stuff separately (test code) or the
syntax updater.
This comes with a factory function that re-directs to the backend and a
run member function to replace
sixtyfps_runtime_run_component_with_gl_renderer. For now it's all still
hidden in the generated run() method.
Use a full prefixed name (sixtyfps_rendering_backend_gl) to ensure that
the created static lib can be installed without file conflicts (libgl is
not a unique name).
