diff --git a/blog/new-design.md b/blog/new-design.md index 3b4541e..c849af4 100644 --- a/blog/new-design.md +++ b/blog/new-design.md @@ -8,6 +8,8 @@ authors: Greetings to everyone, i haven't been working on OSUI for the past 6 months, i have been busy with other projects and haven't found myself motivated enough for OSUI, now i'm ready to go back to OSUI and make major changes. + + ## ⚡️ Changes - ⚙️ Rewrite the entire codebase @@ -20,7 +22,7 @@ OSUI Components and Extensions are a important design choice for OSUI, They stor ### Extensions -A OSUI extension extends the functionality of the current elements and program, a good example is in our [Hello World App With Velocity](/docs/#hello-world-app-with-velocity) example, where we use the built in `VelocityExtension` as well as the `Velocity(x, y)` component, by design it is required for a extension to have the components be optional for the elements, unless there is a very specific reason not to make it optional. +A OSUI extension extends the functionality of the current elements and program, a good example is in our [Hello World App With Velocity](/docs/0.0.9/#hello-world-app-with-velocity) example, where we use the built in `VelocityExtension` as well as the `Velocity(x, y)` component, by design it is required for a extension to have the components be optional for the elements, unless there is a very specific reason not to make it optional. ### Components diff --git a/blog/osui-rewrite.md b/blog/osui-rewrite.md index f279a0d..8d0ff78 100644 --- a/blog/osui-rewrite.md +++ b/blog/osui-rewrite.md @@ -8,6 +8,8 @@ authors: Why would i bother re-writing a TUI library? Well there was a LOT of things wrong with the old version of OSUI. It had bugs and lacks performance. v0.0.9 fixes all of those and hopefully we can achieve a better future for OSUI. With that being said. Let's get into what i plan on doing. + + ## ⚙️ OSUI Engine OSUI v0.0.9 Comes with a engine that works under the hood and can be manipulated to match your needs. Here are a few examples: - Game engine diff --git a/versioned_docs/version-0.1.0/01-guides/handling_input.md b/versioned_docs/version-0.1.0/01-guides/handling_input.md index 766a1f7..9b46fbd 100644 --- a/versioned_docs/version-0.1.0/01-guides/handling_input.md +++ b/versioned_docs/version-0.1.0/01-guides/handling_input.md @@ -128,7 +128,7 @@ rsx! { Beyond `crossterm` events, you can define and dispatch your own custom event types using the `event!` macro. This is useful for communication between different parts of your application or custom extensions. -See the [Advanced: Custom Events](/docs/advanced/custom_events.md) guide for details. +See the [Advanced: Custom Events](/docs/advanced/custom_events) guide for details. ## Summary diff --git a/versioned_docs/version-0.1.0/01-guides/using_extensions.md b/versioned_docs/version-0.1.0/01-guides/using_extensions.md index 2ec936e..934aa40 100644 --- a/versioned_docs/version-0.1.0/01-guides/using_extensions.md +++ b/versioned_docs/version-0.1.0/01-guides/using_extensions.md @@ -105,10 +105,10 @@ Once registered, the `Screen` will call the appropriate lifecycle methods of you OSUI comes with several useful built-in extensions: -* [`InputExtension`](/docs/reference/extensions_api.md#inputextension): Handles keyboard input and dispatches `crossterm::event::Event`s. **Crucial for interactive applications.** -* [`TickExtension`](/docs/reference/extensions_api.md#tickextension): Dispatches `TickEvent`s at a specified rate, useful for animations or periodic updates. -* [`VelocityExtension`](/docs/reference/extensions_api.md#velocityextension): Automatically updates the `Transform` of widgets that have a `Velocity` component, causing them to move. -* [`IdExtension`](/docs/reference/extensions_api.md#idextension): Provides a way to retrieve specific widgets by a unique `Id` component. (Note: The current `IdExtension` implementation only *stores* a screen reference but doesn't actively do anything unless you manually call its `get_element` method.) +* [`InputExtension`](/docs/reference/extensions_api#inputextension): Handles keyboard input and dispatches `crossterm::event::Event`s. **Crucial for interactive applications.** +* [`TickExtension`](/docs/reference/extensions_api#tickextension): Dispatches `TickEvent`s at a specified rate, useful for animations or periodic updates. +* [`VelocityExtension`](/docs/reference/extensions_api#velocityextension): Automatically updates the `Transform` of widgets that have a `Velocity` component, causing them to move. +* [`IdExtension`](/docs/reference/extensions_api#idextension): Provides a way to retrieve specific widgets by a unique `Id` component. (Note: The current `IdExtension` implementation only *stores* a screen reference but doesn't actively do anything unless you manually call its `get_element` method.) You use these built-in extensions by simply calling `screen.extension(...)` with an instance of them, just like `MyLoggerExtension`. diff --git a/versioned_docs/version-0.1.0/concepts/layout_system.md b/versioned_docs/version-0.1.0/concepts/layout_system.md index 74a045b..d7dee8b 100644 --- a/versioned_docs/version-0.1.0/concepts/layout_system.md +++ b/versioned_docs/version-0.1.0/concepts/layout_system.md @@ -22,7 +22,7 @@ The central component for defining layout rules. It encapsulates all the propert * `px: u16`, `py: u16`: **Padding** - internal space between the element's border and its content/children. This increases the overall size of the element. * `mx: i32`, `my: i32`: **Margin** - an offset applied *after* the element's position is calculated. This creates space *around* the element relative to its parent's edges. Can be negative for overlap. -(See [Reference: Style API - Transform](/docs/reference/style_api.md#transform-component) for full details) +(See [Reference: Style API - Transform](/docs/reference/style_api#transform-component) for full details) ### `Position` Enum @@ -32,7 +32,7 @@ Determines the `x` or `y` coordinate. * `Center`: Centers the element within the parent's available space on that axis. * `End`: Aligns the element to the right or bottom edge of the parent. -(See [Reference: Style API - Position](/docs/reference/style_api.md#position-enum) for full details) +(See [Reference: Style API - Position](/docs/reference/style_api#position-enum) for full details) ### `Dimension` Enum @@ -42,13 +42,13 @@ Determines the `width` or `height`. * `Content`: Sizes itself to fit its content (text) or children. This is dynamic. * `Const(u16)`: Fixed size in terminal cells. -(See [Reference: Style API - Dimension](/docs/reference/style_api.md#dimension-enum) for full details) +(See [Reference: Style API - Dimension](/docs/reference/style_api#dimension-enum) for full details) ### `RawTransform` Struct This is the internal, resolved representation of a `Transform`. After all calculations, a `Transform`'s declarative rules are converted into a `RawTransform` with concrete `u16` values for `x`, `y`, `width`, `height`, `px`, `py`. This `RawTransform` is then used by the `RenderScope` for actual drawing. -(See [Reference: Style API - RawTransform](/docs/reference/style_api.md#rawtransform-struct) for full details) +(See [Reference: Style API - RawTransform](/docs/reference/style_api#rawtransform-struct) for full details) ## Layout Calculation Flow (Simplified) diff --git a/versioned_docs/version-0.1.0/concepts/reactive_updates.md b/versioned_docs/version-0.1.0/concepts/reactive_updates.md index ca00124..1083bbf 100644 --- a/versioned_docs/version-0.1.0/concepts/reactive_updates.md +++ b/versioned_docs/version-0.1.0/concepts/reactive_updates.md @@ -31,7 +31,7 @@ OSUI automates this process. When a `State` value is modified, any `DynWidget * `**my_state.get() = new_value` (or `my_state.get().deref_mut().field = new_value`): Mutates the value directly through a `MutexGuard`. The `DerefMut` implementation automatically marks the state as changed by setting `inner.changed = inner.dependencies`. * **Dependency Tracking**: Implements the `DependencyHandler` trait, allowing `DynWidget`s to register themselves. -(See [Reference: State API](/docs/reference/state_api.md) for more details) +(See [Reference: State API](/docs/reference/state_api) for more details) ### 2. `DependencyHandler` Trait @@ -40,7 +40,7 @@ A trait that `State` (and potentially other future reactive types) implements * `add()`: Called when a `DynWidget` first registers itself as a listener to this dependency. It increments an internal counter of listeners. * `check()`: Called by `DynWidget` during its `auto_refresh` cycle. It decrements the `changed` counter and returns `true` if there are still pending changes to be processed by a listener. This ensures each listener processes a change only once per update cycle. -(See [Reference: State API - DependencyHandler Trait](/docs/reference/state_api.md#dependencyhandler-trait) for more details) +(See [Reference: State API - DependencyHandler Trait](/docs/reference/state_api#dependencyhandler-trait) for more details) ### 3. `DynWidget`: The Reactive Widget Wrapper @@ -54,7 +54,7 @@ A trait that `State` (and potentially other future reactive types) implements * `refresh()`: Forces the widget to rebuild immediately by re-executing its creation closure. * `auto_refresh()`: The core of reactivity. It iterates through all registered `DependencyHandler`s. If `handler.check()` returns `true` for any of them, it calls `refresh()` to rebuild the widget. -(See [Reference: Widget API - DynWidget Struct](/docs/reference/widget_api.md#dynwidget-struct) for more details) +(See [Reference: Widget API - DynWidget Struct](/docs/reference/widget_api#dynwidget-struct) for more details) ## How Reactive Updates Work in Practice diff --git a/versioned_docs/version-0.1.0/concepts/rendering_pipeline.md b/versioned_docs/version-0.1.0/concepts/rendering_pipeline.md index 2b51c79..5a02a70 100644 --- a/versioned_docs/version-0.1.0/concepts/rendering_pipeline.md +++ b/versioned_docs/version-0.1.0/concepts/rendering_pipeline.md @@ -29,7 +29,7 @@ The orchestrator. It holds the list of top-level `Widget`s, manages extensions, * Iterates through top-level widgets, initiating their rendering. * Calls `Extension::on_close` and restores terminal state on shutdown. -(See [Reference: Screen API](/docs/reference/screen_api.md) for more details) +(See [Reference: Screen API](/docs/reference/screen_api) for more details) ### 2. `Widget` (`Arc`) @@ -39,7 +39,7 @@ The container for an `Element` and its `Component`s. It's the unit passed around * `DynWidget`: Its `Element` can be re-instantiated (rebuilt) if its dependencies change. This rebuild happens *before* its `render` method is called in a subsequent frame. * Provides access to its `Element` (`get_elem()`) and `Component`s (`get()`, `set_component()`). -(See [Reference: Widget API](/docs/reference/widget_api.md) for more details) +(See [Reference: Widget API](/docs/reference/widget_api) for more details) ### 3. `Element` (`Box`) @@ -49,7 +49,7 @@ The actual drawable logic. Each `Element` implementation defines how it appears. * `after_render(&mut self, scope: &mut RenderScope)`: For containers, this is where children are processed and recursively rendered. It's also where the element might determine its final `Dimension::Content` size based on children. * `draw_child(&mut self, element: &Arc)`: Called by `rsx!` to establish parent-child relationships. Children processed by a parent are marked `NoRenderRoot` to prevent the `Screen` from rendering them independently. -(See [Reference: Widget API - Element Trait](/reference/widget_api#element-trait) and [Guides: Custom Elements](/docs/guides/custom_elements) for more details) +(See [Reference: Widget API - Element Trait](/docs/reference/widget_api#element-trait) and [Guides: Custom Elements](/docs/guides/custom_elements) for more details) ### 4. `RenderScope` @@ -67,7 +67,7 @@ The drawing context for a single element. It's a mutable structure that holds: * `clear()`: Resets the scope for the next element. * `set_parent_size()`: Crucial for container elements to establish the bounding box for their children. -(See [Reference: RenderScope API](/docs/reference/render_scope_api.md) for more details) +(See [Reference: RenderScope API](/docs/reference/render_scope_api) for more details) ### 5. `Transform` and `Style` Components @@ -76,7 +76,7 @@ These components, attached to a `Widget`, provide the declarative rules for layo * `Transform`: Contains `Position` and `Dimension` rules, plus `margin` and `padding`. These are resolved into `RawTransform` by `RenderScope`. * `Style`: Contains `Background` and `foreground` color. Applied to `RenderScope`. -(See [Reference: Style API](/docs/reference/style_api.md) for more details) +(See [Reference: Style API](/docs/reference/style_api) for more details) ### 6. `Extension`s @@ -84,7 +84,7 @@ Extensions are hooks into the pipeline. * `Extension::render_widget(scope, widget)`: Called for each top-level widget *before* its `Element::render`. Allows extensions to inspect or modify the `RenderScope` or widget before rendering. -(See [Reference: Extensions API](/docs/reference/extensions_api.md) for more details) +(See [Reference: Extensions API](/docs/reference/extensions_api) for more details) ## Flow Diagram (Conceptual) diff --git a/versioned_docs/version-0.1.0/reference/widget_api.md b/versioned_docs/version-0.1.0/reference/widget_api.md index e384dca..aa70e12 100644 --- a/versioned_docs/version-0.1.0/reference/widget_api.md +++ b/versioned_docs/version-0.1.0/reference/widget_api.md @@ -141,7 +141,7 @@ OSUI uses a few internal components to control rendering behavior: * `NoRender`: If a widget has this component, the `Screen`'s main rendering loop will skip rendering it directly. This is typically used for widgets that are managed and rendered by their parent `Element::after_render` method. * `NoRenderRoot`: Similar to `NoRender`, but specifically signals that the widget is a child being managed by a parent element, preventing the `Screen` from considering it a top-level root widget for direct rendering. -* `Handler`: (Described in [Handling Input](/docs/guides/handling_input.md) and [Extensions API](/docs/reference/extensions_api.md)) Enables widgets to subscribe to specific event types. +* `Handler`: (Described in [Handling Input](/docs/guides/handling_input) and [Extensions API](/docs/reference/extensions_api)) Enables widgets to subscribe to specific event types. ## Usage Patterns