pub struct Cx {
pub platform_type: PlatformType,
pub current_dpi_factor: f32,
pub last_event_time: f64,
pub fonts_data: Arc<RwLock<CxFontsData>>,
pub call_rust_async_fn: Option<usize>,
pub app_type_id: TypeId,
/* private fields */
}Expand description
The main “context” object which contains pretty much everything we need within the framework.
Fields
platform_type: PlatformTypeSee PlatformType.
current_dpi_factor: f32The dpi_factor used during the current Pass (since you can override the system default).
See also [PassUniforms::dpi_factor].
More commonly known as the “device pixel ratio”. TODO(JP): Rename?
last_event_time: f64Last timestamp from when an event was fired, in seconds since the application was started. Typically you want to use this instead of making a system call.
fonts_data: Arc<RwLock<CxFontsData>>Fonts specific data It might be possible for fonts data to be shared between different threads, so we need to make use of locks.
call_rust_async_fn: Option<usize>Function registered through Cx::on_call_rust_async
app_type_id: TypeIdReference to the main_app type
Implementations
Request a new redraw of the application.
Sets a ComponentId that will become Cx::key_focus when the current events are handled.
TODO(JP): It’s possible to set this during the draw cycle instead of during an
event handler, and then it won’t update Cx::key_focus until the next event
is handled. We should probably guard against that.
Keep the existing key focus during an Event::PointerDown, because otherwise we’ll reset
it back to Area::Empty.
Reverts back to the previous Cx::key_focus value.
TODO(JP): It’s possible to set this during the draw cycle instead of during an
event handler, and then it won’t update Cx::key_focus until the next event
is handled. We should probably guard against that.
Check if a ComponentId currently has keyboard focus.
Request an Event::NextFrame.
Create a new Signal, which is used to send and capture custom
events.
See also SignalEvent.
Triggers a new SignalEvent with the same ID as Signal. You can
post custom data with it using status.
If you want to fire a SignalEvent from a thread, use Cx::post_signal
instead.
See also SignalEvent.
Change the debug flags, which control various debug functionality.
See CxDebugFlags for more information on the individual flags.
Example:
let flags = cx.debug_flags_mut();
flags.draw_tree = CxDebugDrawTree::Instances;
flags.disable_draw_call_batching = true;Register function to handle callRustSync from JavaScript. Registered function must be a method on the main app.
Set the callback for zaplib.callRustSync calls.
Can only be called in the new function of your app, since we do some thread-unsafe
operations in this, and during new there are no threads yet. We make the assertion
here for consistency, but it’s primarily for on_call_rust_sync_internal
in cx_wasm32.rs.
pub fn call_rust_sync_dispatch(
func: CallRustSyncFn,
name: String,
params: Vec<ZapParam>
) -> Vec<ZapParam>
Mark that the new function of the main app has been called. Automatically called by the main_app! macro;
don’t call this in user code.
Add a slice of instances to DrawCall::instances.
Supports appending any data that has the correct size.
You should assume that any call to this creates a new DrawCall, even though in reality we might
batch certain DrawCalls. For more information about DrawCall batching, see Shader.
Uses Cx::create_draw_call under the hood to find the DrawCall
to add to.
pub fn add_mesh_instances<T: 'static + Copy>(
&mut self,
shader: &'static Shader,
data: &[T],
gpu_geometry: GpuGeometry
) -> Area
pub fn add_mesh_instances<T: 'static + Copy>(
&mut self,
shader: &'static Shader,
data: &[T],
gpu_geometry: GpuGeometry
) -> Area
Add a slice of instances while specifying a custom Geometry
By default, DrawCall gets horizontal and vertical scrolling applied to
its uniforms, but you can disable that by calling this method. This only
applies to scrolling from its direct parent View.
This always creates a new DrawCall; no batching ever happens when using
sticky scrolling.
TODO(JP): The fact that this only applies to the direct parent View
makes it so you can’t just arbitrarily wrap DrawCalls inside Views,
which is somewhat unexpected. It might be better to have this apply to
the nearest zaplib_components::ScrollView instead?
TODO(JP): Do we need to track as fields on DrawCall? The same behavior
can also be accomplished by overriding the Shader’s scroll
function, by doing draw_scroll - draw_local_scroll. It’s not as
convenient, but then again, it might not be used very often, and it would
encourage people to do more stuff in shaders.
Start a “shader group”, which is a group of Shaders that will always be drawn in
the same order.
When drawing the same “shader group” multiple times in a row, the existing DrawCalls
will be reused (batched) instead of new ones being created.
For example, calling cx.begin_shader_group(&[&FOO_SHADER, &BAR_SHADER]); will guarantee
that for that shader group exactly two DrawCalls will be created, with FOO_SHADER
being always drawn first.
End a “shader group”. See Cx::begin_shader_group.
Starts the box that has it elements layed out horizontally (as a row)
Ends the current block that was opened by Cx::begin_row.
Returns a Rect representing the overall area of that row
Starts the box that has it elements layed out vertically (as a column)
Ends the current block that was opened by Cx::begin_column.
Returns a Rect representing the overall area of that column
Starts alignment element that fills all remaining space by y axis and centers content by it
Starts alignment element that fills all remaining space in box and centers content by x and y
Starts alignment element that fills all remaining space by x axis and centers content by it
Start new box that will be on the right by x axis
Starts a new box that adds padding to current box context
Ends the current box that was opened by Cx::begin_padding_box
Starts new box that is absolutely positioned at (0, 0) coordinate
Ends the current box that was opened by Cx::begin_absolute_box
Starts new box that is wrapping its content inside.
This is defined in terms of child boxes (e.g. if any of the immediately nested boxes
goes beyond the bounds, it would be wrapped to new line).
This is only supported for horizontal direction.
Note: text has its own wrapping mechanism via TextInsProps::wrapping.
Ends the current box that was opened by Cx::begin_wrapping_box
Returns the full rect corresponding to current box.
It uses all available_width/height plus padding.
Note that these are the inherent dimensions of the [CxLayoutBox], not
what the [CxLayoutBox] has walked so far. See Cx::get_box_bounds for that.
Get some notion of the width that is “left” for the current [CxLayoutBox].
See also Cx::get_width_total.
Get some notion of the total width of the current box. If the width is well defined, then we return it. If it’s computed, then we return the bound (including padding) of how much we’ve drawn so far. And if we haven’t drawn anything, we return 0.
Get some notion of the height that is “left” for the current [CxLayoutBox].
See also Cx::get_height_total.
Get some notion of the total height of the current box. If the height is well defined, then we return it. If it’s computed, then we return the bound (including padding) of how much we’ve drawn so far. And if we haven’t drawn anything, we return 0.
Get the bounds of what the box has actually moved (not just its
inherent width/height as given by Cx::get_box_rect), including any padding that the
layout of the current box specifies.
Same as [Cx::get_box_rect().pos].
TODO(JP): Do we really need two different methods to get to the same data?
Get the current [CxLayoutBox::pos] in absolute coordinates.
TODO(JP): Only used in two places currently; do we really need this?
Adds Box to current [CxLayoutBox], returning a Rect of its size
Manually change [CxLayoutBox::pos]. Warning! Does not update [CxLayoutBox::bound_right_bottom],
like Cx::add_box does; might result in unexpected behavior.
TODO(JP): Should we delete this and just always use Cx::add_box instead?
Manually change [CxLayoutBox::pos]. Warning! Does not update [CxLayoutBox::bound_right_bottom],
like Cx::add_box does; might result in unexpected behavior.
TODO(JP): Should we delete this and just always use Cx::add_box instead?
Explicitly move the current [CxLayoutBox] to a new line.
TODO(JP): Mostly relevant for Direction::Right, should we just disable
this for Direction::Down to avoid confusion?
Cx::draw_new_line but allows setting a minimum height for the line.
TODO(JP): Should we instead include min_height in [Layout]?
Collection of standard Shader functions.
Trait Implementations
See CxDesktopVsWasmCommon::get_default_window_size for documentation.
See CxDesktopVsWasmCommon::file_write for documentation.
See CxDesktopVsWasmCommon::websocket_send for documentation.
See CxDesktopVsWasmCommon::http_send for documentation.
This never gets called if cef is not enabled, but we need it to pass compilation.
See CxPlatformCommon::show_text_ime for documentation.
See CxPlatformCommon::hide_text_ime for documentation.
See CxPlatformCommon::start_timer for documentation.
See CxPlatformCommon::stop_timer for documentation.
See CxPlatformCommon::post_signal for documentation.
See CxPlatformCommon::update_menu for documentation.
See CxPlatformCommon::update_menu for documentation.
Send zaplib Event for processing from any thread