ratatui_ruby 0.4.0 → 0.6.0

data/doc/contributors/developing_examples.md

@@ -18,11 +18,12 @@ require "ratatui_ruby"
 
 class MyExampleApp
   def initialize
-    # Initialize state
+    # Initialize state (styles must be initialized in run when @tui is available)
   end
 
   def run
-    RatatuiRuby.run do
+    RatatuiRuby.run do |tui|
+      @tui = tui  # Store for use in private methods
       loop do
         render
         break if handle_input == :quit
@@ -33,13 +34,24 @@ class MyExampleApp
   private
 
   def render
-    # Build and draw UI
-    RatatuiRuby.draw(layout)
+    @tui.draw do |frame|
+      # 1. Split layout using Session helpers
+      areas = @tui.layout_split(frame.area, constraints: [@tui.constraint_fill(1)])
+      # 2. Create and render widgets
+      widget = @tui.paragraph(text: "Hello", block: @tui.block(borders: [:all]))
+      frame.render_widget(widget, areas[0])
+    end
   end
 
   def handle_input
-    event = RatatuiRuby.poll_event
-    # Process event, return :quit to exit
+    case @tui.poll_event
+    in { type: :key, code: "q" }
+      :quit
+    in { type: :key, code: code }
+      # Handle other keys
+    else
+      # Ignore unhandled events
+    end
   end
 end
 
@@ -48,11 +60,12 @@ MyExampleApp.new.run if __FILE__ == $PROGRAM_NAME
 
 ### Naming Convention (Required)
 
-Example classes **must** follow the naming convention:
-- **Directory:** `examples/my_example/` (snake_case)
-- **Class:** `MyExampleApp` (PascalCase with `App` suffix)
+Example directories **must** follow a prefixing convention to categorize them alphabetically:
+- `app_`: Application showcases (e.g., `app_analytics`). Class name: `AppAnalytics`.
+- `widget_`: Widget-focused demonstrations (e.g., `widget_gauge_demo`). Class name: `WidgetGaugeDemo`.
+- `verify_`: Documentation verification examples (e.g., `verify_readme_usage`). Class name: `VerifyReadmeUsage`.
 
-The class name is derived from the directory name: `my_example` → `MyExampleApp`.
+The directory and class names must match (snake_case directory maps to PascalCase class).
 
 This convention enables the `terminal_preview:update` rake task to automatically capture terminal output for all examples without maintaining a manual registry.
 
@@ -71,9 +84,11 @@ All interactive examples must fit within an **80×24 terminal** (standard VT100
 - **Style hotkeys visually:** Use `modifiers: [:bold, :underlined]` on hotkey letters to make them stand out from descriptions. Example: `i` (bold, underlined) followed by `Items`.
 - Test early by running the example at 80×24 and verifying all content is visible without wrapping, scrolling, or clipping.
 
-Every example must also have an RBS file documenting its public methods:
+## Type Signatures
 
-`examples/my_example/app.rbs`:
+Every example must also have an RBS file documenting its public methods. Type signatures live in a centralized location:
+
+`sig/examples/my_example/app.rbs`:
 ```rbs
 class MyExampleApp
   # @public
@@ -84,19 +99,75 @@ class MyExampleApp
 end
 ```
 
+## Directory Structure
+
+Examples are organized across three locations:
+
+```
+examples/
+  my_example/
+    app.rb              ← REQUIRED: The runnable example code
+    README.md           ← REQUIRED: Purpose, architecture, hotkeys, usage
+
+test/examples/
+  my_example/
+    test_app.rb         ← REQUIRED: Tests (centralized, not local to example)
+    snapshots/          ← Auto-created by assert_snapshot
+      initial_render.txt
+
+sig/examples/
+  my_example/
+    app.rbs             ← REQUIRED: Type signatures (centralized, not local to example)
+```
+
 ### Key Requirements
 
 1. **Only `run` should be public.** All other methods (`render`, `handle_input`, helper methods) must be private. This prevents tests from calling internal methods directly.
 
 2. **Use `RatatuiRuby.run` for terminal management.** Never call `init_terminal` or `restore_terminal` directly. The `run` block handles terminal setup/teardown automatically and safely, even if an exception occurs.
 
-3. **Use keyboard keys to cycle through widget attributes.** Users should be able to interactively explore all widget options. Common patterns:
+3. **Use the Session API (`tui`) for cleaner code.** Accept the `tui` block parameter from `RatatuiRuby.run` and use it throughout your app:
+   - `@tui.draw { |frame| ... }` instead of `RatatuiRuby.draw`
+   - `@tui.poll_event` instead of `RatatuiRuby.poll_event`
+   - `@tui.style(...)` instead of `RatatuiRuby::Style.new(...)`
+   - `@tui.paragraph(...)` instead of `RatatuiRuby::Paragraph.new(...)`
+   - `@tui.block(...)` instead of `RatatuiRuby::Block.new(...)`
+   - `@tui.layout_split(...)` instead of `RatatuiRuby::Layout.split(...)`
+   - `@tui.constraint_fill(...)` instead of `RatatuiRuby::Constraint.fill(...)`
+   - `@tui.text_line(...)` instead of `RatatuiRuby::Text::Line.new(...)`
+   - `@tui.text_span(...)` instead of `RatatuiRuby::Text::Span.new(...)`
+
+4. **Event handling must include a catch-all pattern.** When using pattern matching in `handle_input`, always include an `else` clause at the end to catch unmatched events (mouse events, resize events, focus events, etc.). Without it, unmatched events will raise `NoMatchingPatternError`:
+
+   ```ruby
+   def handle_input
+     case @tui.poll_event
+     in { type: :key, code: "q" }
+       :quit
+     in { type: :mouse, kind: "down", x:, y: }
+       handle_click(x, y)
+     else
+       # Ignore other events
+     end
+   end
+
+5. **Use keyboard keys to cycle through widget attributes.** Users should be able to interactively explore all widget options. Common patterns:
     - Arrow keys: Navigate or adjust values
     - Letter keys: Cycle through styles, modes, or variants. Prefer all lowercase keys to avoid confusion and simplify the UI description.
     - Space: Toggle or select
     - `q` or Ctrl+C: Quit
 
-### Naming Conventions for Controls
+6. **All examples must include a README.md** explaining:
+   - What problem the example solves
+   - Architecture (if applicable)
+   - Hotkeys (if interactive): Document all keyboard/mouse controls
+   - Key concepts demonstrated
+   - Usage instructions
+   - Learning outcomes
+
+   See examples/app_color_picker/README.md and examples/app_all_events/README.md for patterns. Adhere to docs/contributors/documentation_style.md.
+
+7. **Naming Conventions for Controls**
 
 When documenting hotkeys and cycling options in the UI, use consistent naming:
 
@@ -105,11 +176,12 @@ When documenting hotkeys and cycling options in the UI, use consistent naming:
   - Use "Highlight Style" (not "Highlight") for the `highlight_style:` parameter
   - Use "Repeat Symbol" (not "Repeat") for the `repeat_highlight_symbol:` parameter
   
-- **Display names for cycled values:** Create a `name` field in your options hash to keep display names paired with values:
+- **Display names for cycled values:** Create a `name` field in your options hash to keep display names paired with values. Initialize style arrays inside `run` when `@tui` is available:
   ```ruby
+  # In run method, after @tui = tui:
   @styles = [
-    { name: "Yellow Bold", style: RatatuiRuby::Style.new(fg: :yellow, modifiers: [:bold]) },
-    { name: "Blue on White", style: RatatuiRuby::Style.new(fg: :blue, bg: :white) }
+    { name: "Yellow Bold", style: @tui.style(fg: :yellow, modifiers: [:bold]) },
+    { name: "Blue on White", style: @tui.style(fg: :blue, bg: :white) }
   ]
   
   # In controls: "h: Highlight Style (#{@styles[@style_index][:name]})"
@@ -118,17 +190,21 @@ When documenting hotkeys and cycling options in the UI, use consistent naming:
 
 This keeps the UI self-documenting and users can see exact parameter names when they read the hotkey help.
 
-### Hit Testing with the Cached Layout Pattern
+8. **Hit Testing**
 
-Examples with mouse interaction should implement the **Cached Layout Pattern** documented in `doc/interactive_design.md`. The `hit_test` example demonstrates this pattern.
+Examples with mouse interaction should use the **Frame API**. By calling `@tui.layout_split` inside `@tui.draw`, you obtain the exact `Rect`s used for rendering. Store these rects in instance variables (e.g., `@sidebar_rect`) to use them in your `handle_input` method for hit testing:
 
-## Testing Examples
+```ruby
+if @sidebar_rect&.contains?(event.x, event.y)
+  # Handle click
+end
+```
 
-Example tests live alongside examples as `test_app.rb` files in the same directory.
+## Testing Examples
 
-### Testing Pattern
+Example tests live in a centralized test tree:
 
-`examples/my_example/test_app.rb`:
+`test/examples/my_example/test_app.rb`:
 ```ruby
 $LOAD_PATH.unshift File.expand_path("../../lib", __dir__)
 require "ratatui_ruby"
@@ -145,44 +221,75 @@ class TestMyExampleApp < Minitest::Test
 
   def test_initial_render
     with_test_terminal do
-      inject_key(:q)  # Queue quit event
-      @app.run        # Run the app loop
-      
-      content = buffer_content.join("\n")
-      assert_includes content, "Expected Text"
+      inject_key(:q)
+      @app.run
+      assert_snapshot("initial_render")
     end
   end
+end
+```
 
-  def test_keyboard_interaction
-    with_test_terminal do
-      inject_key("s")  # Press 's' to cycle something
-      inject_key(:q)   # Then quit
-      @app.run
+## Snapshot Testing Pattern (REQUIRED)
 
-      content = buffer_content.join("\n")
-      assert_includes content, "Changed State"
-    end
+All example tests MUST use snapshot testing via the `assert_snapshot` API, not manual content assertions.
+
+### Why Snapshots
+
+- **Exact verification:** Captures complete screen state, character-by-character
+- **Auto-update:** `UPDATE_SNAPSHOTS=1 bin/agent_rake test` regenerates all snapshots
+- **Auto-managed:** Snapshots live in `test/examples/{name}/snapshots/{test_name}.txt`
+- **Maintainable:** No tedious manual string checks
+- **Self-documenting:** Snapshots show exactly what output is expected
+
+### Basic Pattern
+
+```ruby
+def test_initial_render
+  with_test_terminal do
+    inject_key(:q)
+    @app.run
+    
+    assert_snapshot("initial_render")
   end
 end
 ```
 
-### Testing Guidelines
+Snapshot auto-saved to: `test/examples/widget_foo_demo/snapshots/initial_render.txt`
 
-1. **Inject events, observe buffer.** Tests should only interact through:
-   - `inject_key` / `inject_keys` / `inject_event` for input
-   - `buffer_content` for output verification
+### With Normalization (for dynamic content)
 
-2. **Never call internal methods.** Don't call `render`, `handle_input`, `__send__`, or access instance variables with `instance_variable_get`. Tests verify behavior through the public `run` method.
+For examples with timestamps, random data, or other non-deterministic output:
 
-3. **Use `inject_key(:q)` to exit.** All examples should support quitting with `q`, so inject this as the final event to terminate the loop.
+```ruby
+private def assert_normalized_snapshot(snapshot_name)
+  assert_snapshot(snapshot_name) do |actual|
+    actual.map do |line|
+      line.gsub(/\d{2}:\d{2}:\d{2}/, "XX:XX:XX")  # Mask timestamps
+           .gsub(/Random ID: \d+/, "Random ID: XXX")  # Mask random values
+    end
+  end
+end
 
-4. **Assert and refute.** When testing which item was clicked/selected, also verify the opposite didn't happen:
-   ```ruby
-   assert_includes content, "Left Panel clicked"
-   refute_includes content, "Right Panel clicked"
-   ```
+def test_after_event
+  with_test_terminal do
+    inject_key("a")
+    inject_key(:q)
+    @app.run
+    
+    assert_normalized_snapshot("after_event")
+  end
+end
+```
+
+See `test/examples/app_all_events/test_app.rb` for a complete example.
+
+### Regenerating Snapshots
+
+When UI changes are intentional, regenerate all snapshots:
 
-5. **Test state cycling.** If an example cycles through options (styles, modes, etc.), test that pressing the key actually changes the rendered output.
+```bash
+UPDATE_SNAPSHOTS=1 bin/agent_rake test
+```
 
 ## Widget Attribute Cycling
 
@@ -201,3 +308,39 @@ Examples should demonstrate widget configurability by allowing interactive cycli
 | Scrollbar | theme | s |
 
 Display the current state in the UI (e.g., in a title or status bar or paragraph) so users can see what changed. Display the hotkey in the UI as well, so users can see how to change it; the hotkey should not disappear as app state changes.
+
+## Data Quality
+
+Examples must use **realistic, meaningful data**—not dummy placeholder text. This ensures examples:
+- Demonstrate the widget's real-world usage
+- Provide educational value to users reading the code
+- Look professional and polished
+
+### Guidelines
+
+**For small datasets (< 10 items):**
+Use hardcoded realistic data. Examples:
+- Geographic coordinates with city names (see `widget_map_demo/app.rb`)
+- Real product names or person names
+- Meaningful status values ("Completed", "Pending", "Failed")
+
+**For large datasets (≥ 10 items):**
+Use the [Faker](https://github.com/faker-ruby/faker) gem with **deterministic seeding** so data is consistent across runs:
+
+```ruby
+require "faker"
+
+# Seed Faker for reproducible output
+Faker::Config.random = Random.new(12345)
+
+# Generate realistic data
+users = Array.new(50) { Faker::Name.name }
+emails = Array.new(50) { Faker::Internet.email }
+```
+
+In tests, set the same seed before each test to ensure snapshot consistency.
+
+**Avoid:**
+- Repeated placeholder text like "Lorem ipsum" or "Background Layer" × 20
+- Generic numbered items like "Item 1", "Item 2" (unless the context demands it)
+- Nonsensical or visually jarring content

data/doc/contributors/documentation_style.md

@@ -1,3 +1,9 @@
+<!--
+SPDX-FileCopyrightText: 2025 Kerrick Long <me@kerricklong.com>
+
+SPDX-License-Identifier: AGPL-3.0-or-later
+-->
+
 # Documentation Style Guide
 
 This project follows a strict and specific documentation style designed to be helpful, readable, and consistent. It combines the structural clarity of Christopher Alexander's Pattern Language with the prose style of William Zinsser's *On Writing Well* and the usability of the U.S. Federal Plain Language Guidelines.
@@ -9,6 +15,7 @@ This project follows a strict and specific documentation style designed to be he
 *   **Context, Problem, Solution (Alexandrian Form):** Do not just say *what* a class does. Explain *why* it exists. Start with the context, state the problem (the pain point without this tool), and then present the class as the solution.
 *   **Prose Style (Zinsser/Klinkenborg):** Use short, punchy sentences. Use active voice. Cut unnecessary words. Avoid "allow," "enable," "provide," "support," "functionality," and "capability" where possible. Weak verbs hide the action. Strong verbs drive the sentence.
 *   **User-Centric (Plain Language):** Speak directly to the user ("You"). Don't abstract them away ("The developer"). Focus on their goals and how this tool helps them achieve those goals.
+*   **Tone (Supportive and Authoritative, not Hostile or Prescriptive):** Avoid "must," "requires," "need to," or "mandatory." These words sound bossy. Treat the user as a capable peer. Instead of "You must do X," use imperative "Do X" or cause-and-effect "X ensures Y."
 
 ## 2. Class Documentation
 

data/doc/contributors/examples_audit/p1_high.md

@@ -0,0 +1,21 @@
+<!--
+SPDX-FileCopyrightText: 2025 Kerrick Long <me@kerricklong.com>
+SPDX-License-Identifier: CC-BY-SA-4.0
+-->
+
+# Priority 1: High (Polish & Ecosystem)
+
+Important for v1.0.0 quality and ecosystem goals. Not blocking release, but recommended before ship.
+
+---
+
+## 1. Ensure All Widgets Have Examples
+
+**Status:** Done
+
+Verified that all widget types shipped with ratatui_ruby have at least one example showing how to use them.
+
+**Action:**
+- [x] Check widget manifest against example inventory
+- [x] Create `widget_canvas_demo`, `widget_center_demo`, and `widget_overlay_demo`
+

data/doc/contributors/examples_audit/p2_moderate.md

@@ -0,0 +1,81 @@
+<!--
+SPDX-FileCopyrightText: 2025 Kerrick Long <me@kerricklong.com>
+SPDX-License-Identifier: CC-BY-SA-4.0
+-->
+
+# Priority 2: Moderate (Quality Gates)
+
+These are v1.0.0 quality improvements that refine the example suite after P0 is complete. Not blocking, but recommended for maintainability and API consistency.
+
+---
+
+## 1. Add RDoc Cross-Links (Examples & Aliases)
+
+**Status:** Important for API discoverability — Documentation should link library and examples
+
+RDoc should cross-link between:
+- **Library classes/methods** ↔ **Examples that use them** (See also: examples/widget_foo_demo)
+- **Primary methods** ↔ **DWIM/TIMTOWTDI aliases** (See also: tui.foo_bar as alias for tui.foo(:bar))
+
+### Current Practice
+
+Done for:
+- `RatatuiRuby::Frame#set_cursor_position` ↔ `RatatuiRuby::Cursor` (cross-linking)
+- Limited elsewhere
+
+### Gaps
+
+- Most widget classes have no "See also: example_foo_demo" links
+- Aliases/TIMTOWTDI variants are not documented as such
+- Users can't easily find examples for a given class/method
+
+### Action
+
+1. Add `# See also: examples/widget_foo_demo/app.rb` to class/method RDoc
+2. Link DWIM methods to TIMTOWTDI variants: `# Also available as: tui.constraint_length (DWIM) vs tui.constraint(:length) (TIMTOWTDI)`
+3. Create consistent pattern across all public APIs in `lib/ratatui_ruby/`
+
+### Example Pattern
+
+```ruby
+# Renders text with styling.
+#
+# See also: examples/widget_paragraph_demo/app.rb (basic paragraph rendering)
+class Paragraph < Data.define(...)
+  # ...
+end
+
+# DWIM version of constraint creation
+# Also available as: constraint(type, value) for explicit control
+def constraint_length(length)
+  constraint(:length, length)
+end
+```
+
+---
+
+## Dependencies
+
+- P0 (developing_examples.md, README.md, tests) should be complete before consolidation
+
+---
+
+## 4. Enhance Widget Examples with Functional Context
+
+**Status:** Recommended — Move beyond "parameter playgrounds" to "real-world patterns"
+
+Current `widget_*` examples mostly focus on interactive parameter turning (changing colors, borders, etc.). While useful for API discovery, they don't show *how* to use the widget in a real application logic flow.
+
+### The Standard: widget_tabs_demo
+
+The `widget_tabs_demo` was enhanced to show **conditional rendering** of content based on the selected tab in git commit `38ceed39a011d557cc66e11a4598d3341dc7a0cc`. It doesn't just highlight the tab; it changes the screen content. This connects the widget (the tabs) to the problem it solves (view segregation).
+
+### Action
+
+Identify other widget examples that could benefit from this "functional context" treatment:
+
+-   **widget_popup_demo:** Show a multi-step modal flow (e.g., Confirm -> Success) rather than just a static overlay.
+-   **widget_list_demo:** Show a master-detail view where selecting a list item updates a detail pane.
+-   **widget_input_demo:** (If created) Show specific validation logic (email vs number).
+
+**Goal:** Every widget example should answer "How do I build a feature with this?" not just "What does this parameter do?"

data/doc/contributors/examples_audit.md

@@ -0,0 +1,41 @@
+<!--
+SPDX-FileCopyrightText: 2025 Kerrick Long <me@kerricklong.com>
+SPDX-License-Identifier: CC-BY-SA-4.0
+-->
+
+# Examples Audit Report
+
+Audit of ratatui_ruby `examples/` directory for v1.0.0 readiness.
+
+## P0: Critical (Completed ✓)
+
+All P0 critical items have been completed:
+
+1. **Migrate Example Tests to Snapshot API** ✓
+   - Migrated 31 test files from manual `buffer_content` assertions to `assert_snapshot` and `assert_rich_snapshot`
+   - Added deterministic seeding for tests with random content (Faker, RATA_SEED)
+   - Generates `.txt` (plain) and `.ansi` (styled) snapshots for mutation-testing capability
+
+---
+
+## [P1: High (Polish)](./examples_audit/p1_high.md)
+
+1. **[Ensure All Widgets Have Examples](./examples_audit/p1_high.md#1-ensure-all-widgets-have-examples)** (Completeness)
+   - Check widget manifest against example inventory
+   - Create examples for any missing widgets
+
+---
+
+## [P2: Moderate (Quality)](./examples_audit/p2_moderate.md)
+
+1. **[Add RDoc Cross-Links](./examples_audit/p2_moderate.md#1-add-rdoc-cross-links-examples--aliases)** (Documentation discoverability)
+   - Link library classes/methods to examples
+   - Link DWIM/TIMTOWTDI aliases
+   - Create consistent pattern across public APIs
+
+---
+
+## Success Criteria for v1.0.0
+
+- ✓ All P0 items are fixed
+- ✓ All P1 items are mitigated (or time has run out)

data/doc/contributors/index.md

@@ -11,6 +11,8 @@
 - [Documentation Guide](https://man.sr.ht/~kerrick/ratatui_ruby/documentation_guide.md)
 - [The Design of **ratatui_ruby**](./design.md)
 
+
+
 ## Documentation for Users
 
 - [README](../../README.md)

data/doc/event_handling.md

@@ -1,10 +1,24 @@
+<!--
+SPDX-FileCopyrightText: 2025 Kerrick Long <me@kerricklong.com>
+
+SPDX-License-Identifier: AGPL-3.0-or-later
+-->
+
 # Event Handling in RatatuiRuby
 
 `ratatui_ruby` provides a rich, object-oriented event system that supports multiple coding styles, from simple boolean predicates to modern Ruby pattern matching.
 
-Events are retrieved using `RatatuiRuby.poll_event`. This method returns an instance of a subclass of `RatatuiRuby::Event` (e.g., `RatatuiRuby::Event::Key`, `RatatuiRuby::Event::Mouse`) or `nil` if no event is available.
+Events are retrieved using `RatatuiRuby.poll_event`. This method returns an instance of a subclass of `RatatuiRuby::Event` (e.g., `RatatuiRuby::Event::Key`, `RatatuiRuby::Event::Mouse`). When no event is available, it returns `RatatuiRuby::Event::None`—a [null object](https://martinfowler.com/eaaCatalog/specialCase.html) that safely responds to all event predicates with `false`.
+
+## 1. Blocking vs. Polling
+
+Most applications run in a loop (e.g., a game loop or UI loop). To prevent high CPU usage, the loop should wait briefly for input.
+
+*   **Default (Polling):** `RatatuiRuby.poll_event` (no args) waits for **0.016s** (approx 60 FPS). If no event occurs, it returns `RatatuiRuby::Event::None`. This keeps the application responsive.
+*   **Blocking:** `RatatuiRuby.poll_event(timeout: nil)` waits **forever** until an event occurs. Use this for scripts that only react to input and do not need to update the UI on a timer.
+*   **Non-Blocking:** `RatatuiRuby.poll_event(timeout: 0.0)` returns immediately.
 
-## 1. Symbol and String Comparison (Simplest)
+## 2. Symbol and String Comparison (Simplest)
 
 For simple key events, `RatatuiRuby::Event::Key` objects can be compared directly to Symbols or Strings. This is often the quickest way to get started.
 
@@ -18,7 +32,6 @@ For a complete list of supported keys, modifiers, and event types, please refer
 
 ```ruby
 event = RatatuiRuby.poll_event
-next unless event
 
 # 1. Check for quit keys
 if event == "q" || event == :ctrl_c
@@ -31,7 +44,7 @@ if event == :enter
 end
 ```
 
-## 2. Predicate Methods (Intermediate)
+## 3. Predicate Methods (Intermediate)
 
 If you need more control or logic (e.g. `if/elsif`), or need to handle non-key events like Resize or Mouse, use the predicate methods.
 
@@ -77,7 +90,7 @@ if event.mouse? && event.scroll_up?
 end
 ```
 
-## 3. Pattern Matching (Powerful)
+## 4. Pattern Matching (Powerful)
 
 For complex applications, Ruby 3.0+ Pattern Matching with the `type:` discriminator is the most idiomatic and concise approach.
 
@@ -101,8 +114,8 @@ loop do
   in type: :mouse, kind: "down", x:, y:
     handle_click(x, y)
 
-  else
-    # Ignore
+  in type: :none
+    # No event available, continue loop
   end
 end
 ```
@@ -117,3 +130,4 @@ end
 | `RatatuiRuby::Event::Paste` | `:paste` | `content` | `paste?` |
 | `RatatuiRuby::Event::FocusGained` | `:focus_gained` | (none) | `focus_gained?` |
 | `RatatuiRuby::Event::FocusLost` | `:focus_lost` | (none) | `focus_lost?` |
+| `RatatuiRuby::Event::None` | `:none` | (none) | `none?` |