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
Move the rendering preparation, actual rendering and input processing
callbacks into standalone functions. They don't
really need to be variable parameters.
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.
This introduces a separate rendering preparation step in the main
window. As a consequence, the component becomes a parameter and the
graphicstest example can't use the main window anymore.
The decision whether a new low-level primitive needs to be created or
not is made by comparing the last RenderingPrimitive against the new
one.
On the upside, this means that property changes are now reflected in the
graphics.
The source property is a path relative to the path of the executable.
That is still rather inconvenient. It would be more convenient to make
it relative to the source file, but the corresponding proc-macro span
source_file() accessor is not public/stable.
Perhaps there's a way of doing this also through the generated code and
std::file!().
Make our GL context not current when done with the initialization
and make it current for the duration fo primitive creation and frame
rendering.
Fixes#4