Struct zaplib::Cx

source · []
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: PlatformTypecurrent_dpi_factor: f32

The 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: f64

Last 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: TypeId

Reference 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.

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.

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.

Sets the horizontal scroll position for a View/CxView.

Sets the vertical scroll position for a View/CxView.

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::file_write 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

Auto Trait Implementations

Blanket Implementations

Gets the TypeId of self. Read more

Immutably borrows from an owned value. Read more

Mutably borrows from an owned value. Read more

Performs the conversion.

Performs the conversion.

The type returned in the event of a conversion error.

Performs the conversion.

The type returned in the event of a conversion error.

Performs the conversion.