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: PlatformType
See PlatformType
.
current_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
.
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 DrawCall
s. 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 DrawCall
s inside View
s,
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 Shader
s that will always be drawn in
the same order.
When drawing the same “shader group” multiple times in a row, the existing DrawCall
s
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 DrawCall
s 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