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 adds horizontal_alignment/vertical_alignment properties, along with
width/height to Text.
This still uses a hard-coded enumeration in the compiler, which is meant
to go away in favor of general enum support.
We were not parsing CodeBlock node from the signal handler correctly,
we wer eonly taking the first expression instead of the whole codeblock
In JS, emitting signal before the show() did not update the GLOBAL_CONTEXT
needed to emit signals defined in JS
The Rectangle element has properties for a border outline. If those are
used, then the generated code should use BorderRectangle. But if they are
not used, then we can fall back to just generating a Rectangle.
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
