two problems
- For the interpreter, properly handle the case of an alias to a global
- For the rust generator, we can't return a reference to a property held
in a global, so we must 'inline' the get_xx funciton on sub-components
For the MCU port, we need to proccess the image to save them in the binary
in a convenient format.
This patch start this work by trying to anaylyze what format should an image
be using, and saving it as a texture in the binary.
The current graphical backend and the C++ frontend are not yet supported
This will allow later to be able to operate on the binding despite the
element is borrowed.
Since the Binding itself is in a RefCell, the analysis don't need to
be anymore.
To do this change, a small change in the binding_analysis logic was required
which means that we will now detect binding loop if a binding was causing
two binding loop. (before, only one binding loop was detected)
Pass the sub-component as a parameter in enter_component(), as it's needed in the C++
implementation, it's readily available (no need to unwrap again) and Rust will need it, too.
Avoid creating an intermediate array of items to free the graphics resources.
Instead call run-time function with the item tree as a parameter, which is traversed.
It's practically the same data structure that was previously created, except
that it is shared/global and has little holes for the dynamic tree items, but those are easy to skip.
This is done by exposing the ModelNotify to the caller via the new
ModelTracker trait, which has a function that allows "hooking" into the
dirty tracking of the size.
By extension, this also works in JavaScript.
cc #98
This is a two-stage change, that first centralizes the file I/O code
path for on-disk and builtin:/ files. Secondly the resource embedding
pass now produces diagnostics if a file cannot be located.
For loading images that are included in the widget library that's included in turn
in the compiler binary, we need to create ImageInner::EmbeddedData
with &'static data and &'static file extension. The latter was
created using string interning, but we can also access the path of the
widget library data structure.
The GL backend defaults to enabling X11. The default crate depends on
the GL backend but it doesn't specify default-features = false,
therefore x11 is basically always enabled.
In line with commit 1fd8c7236a, this
change makes sure that the defaults are defined in the tree entry
points: The Rust API crate, the interpreter crate and the CMake project
define the defaults. The latter already enabled X11 by default, but the
first two did not.
In ComponentDescription only keep a exported_globals_by_name that
maintains the index in the compiled_globals vector and in there store
the public properties of global singletons.
Even if SIXTYFPS_BACKEND_GL is set to OFF, we would default to enabling
X11, which translates to enabling the x11 feature, which in turn
implicitly activates the GL backend. In addition, the interpreter Rust
API crate also enables the GL backend in its defeaults.
In order to make it possible to turn off the GL backend, three changes are necessary:
* The default backend no more selects a default :-). Instead the Rust
API crate, Rust interpreter API crate and the CMake project define
the same features and defaults.
* The C++ crate depends on the interpreter without its defaults (which enable GL)
* In CMake the X11 and Wayland features become dependent options, that
are only show in the CMake configure UI if the GL backend is enabled.
This way a GL-disabled build won't also pass --features x11.
Like CSS image-rendering it has "smooth" and "pixelated" options.
Only OpenGL has been tested right now, have not tested WASM or Qt.
Right now the first instance of a @image-url() will set the scaling
for that specific image. The same image used from memory on the otherhand
can all have a different scaling property.
Remove the internal name again and pick the first exported one when
assigning ids. This avoids internal names showing up in code completion
or the internal types leaking into generated code.
When exporting an global multiple times under different names, make sure
that they alias in the generated code.
As a consequence, the compiler maintains the original unique name and in
Rust and C++ makes only the exported names public. In the interpreter
the internal name is theoretically still accessible from the outside.
