I tried passing this as a component of the file name (uri style with a query),
but nodejs wants only valid paths for
require() calls. So instead this uses simply an environment variable.
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.
When the path was constructed from events (SVG commands), then we don't really need to build an intermediate path,
neither for rendering nor for path layouting.
Use two arrays, one for events and one for coordinates. That simplifies
the code generator and the generated code, and it also provides for
a more compact memory representation.
They are represented as lyon-style path events. We can use this to
compile SVG paths ahead of time and use them
without including lyon's SVG path builder.
Removed the drop and create from the ComponentVTable:
since we are not using VBox<ComponentVTable>, this simplifies a bit
the code of the interpreter and everything else.
But there is still a lot of changes everywhere to support that the Component
is pinned.
This is just for the component. Which would be required if later we want
to access the properties as Pin<Property<_>>. But we have not yet ability
to do projections
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.
No need to chack that the signal exist since `emit_signal` will
actually return an error in that case already, and this is not
possible to call emit_signal on a invalid signal from the public
API
The test is unrelated
This is relatively straight-forward via a pass in the compiler to
collect the resources to embed and then use include_bytes! (once per
resource).
What's really annoying is that the rust resource enum can't store a
&'static [u8] because cbindgen doesn't represent that, probably because
the slice representation isn't guaranteed to stay as it is. So instead
this, for now, uses raw pointers.
The Image's source property used to be a string. Now it is a Resource
enum, which can either be None or an absolute file path to the image on
disk. This also replaces the internal Image type.
The compiler internally resolves the img bang expression to a resource
reference, which shall remain just an absolute path. For now the target
generator passes that through, but in the future the target generator
may choose a target specific way of embedding the data and thus
generating a different Resource type in the final code (through
compile_expression in the cpp and rust generator).
The C++ binding is a bit messy as cbindgen doesn't really support
exporting enums that can be constructed on the C++ side. So instead we
use cbindgen to merely export the type internally and only use the tag
from it then. The public API is then a custom Resource type that is
meant to be binary compatible.
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).
