yves-biener/zterm
1
0
Fork 0
Code Issues Pull Requests Actions Wiki Activity

lint: correct typos

Yves Biener
2025-07-13 21:10:34 +02:00
parent 131467b718
commit 8a24f23e4d
3 changed files with 6 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Design.md

@@ -15,7 +15,7 @@ The library is designed to be very basic and *not to provide* any more complex e
There are only very few system events, that are used by the built-in containers and properties accordingly. For you own widgets (i.e. a collection of elements) you can extend the events to include your own events to communicate between elements, effect the control flow and the corresponding generated layouts and much more. There are only very few system events, that are used by the built-in containers and properties accordingly. For you own widgets (i.e. a collection of elements) you can extend the events to include your own events to communicate between elements, effect the control flow and the corresponding generated layouts and much more.
> [!TIP] > [!TIP]
> Keep the tagged type of each user event as small as possible. If you need access to bigger structs you can also aways use pointers. > Keep the tagged type of each user event as small as possible. If you need access to bigger structs you can also always use pointers.
This library also provides a rendering pipeline alongside the event loop implementation. Usually the event loop is waiting blocking and will only cause a re-draw (*intermediate mode*) after each event - some events usually don't cause a draw (i.e. `.init` or your own if you want them not to). Even though each frame is regenerated from scratch each render loop, the corresponding application is still pretty performant as the renderer uses a *double buffered* implementation to only apply the changes from each frame to the next to the screen. This library also provides a rendering pipeline alongside the event loop implementation. Usually the event loop is waiting blocking and will only cause a re-draw (*intermediate mode*) after each event - some events usually don't cause a draw (i.e. `.init` or your own if you want them not to). Even though each frame is regenerated from scratch each render loop, the corresponding application is still pretty performant as the renderer uses a *double buffered* implementation to only apply the changes from each frame to the next to the screen.

4
Roadmap.md

@@ -67,7 +67,7 @@ The following list contains goals for certain features the library supports or i
- [x] custom (see example) - [x] custom (see example)
- [x] built-in single line - [x] built-in single line
- [ ] built-in multi line (**later**) - [ ] built-in multi line (**later**)
- [x] overflow handling, i.e. where to draw the elipse `..` - left and right - [x] overflow handling, i.e. where to draw the ellipse `..` - left and right
- [ ] Drop-down menu (`enum`'s) - [ ] Drop-down menu (`enum`'s)
- [x] Radio Button (`bool`'s) - [x] Radio Button (`bool`'s)
- [ ] Slider (range values) - [ ] Slider (range values)
@@ -111,7 +111,7 @@ The following list contains goals for certain features the library supports or i
- [x] `Layout`, `Border` and `Rectangle` contain the test cases for rendering of `Container`s - [x] `Layout`, `Border` and `Rectangle` contain the test cases for rendering of `Container`s
- [x] `Scrollable` test cases containing inclusion of test creation containing user interaction (i.e. mouse scrolling) - [x] `Scrollable` test cases containing inclusion of test creation containing user interaction (i.e. mouse scrolling)
- [x] Debugging - [x] Debugging
- [x] render correpsonding contents with debug information (the following points are just brain dump of potential information the developer want to see): - [x] render corresponding contents with debug information (the following points are just brain dump of potential information the developer want to see):
Top left corner indicates type of contents (if any) while general information is located in the three remaining corners: Top left corner indicates type of contents (if any) while general information is located in the three remaining corners:
- [x] *anchor* of `Container`s (top-left corner -> meaning that is the actual `Cell` used for displaying the debug information) - [x] *anchor* of `Container`s (top-left corner -> meaning that is the actual `Cell` used for displaying the debug information)

6
Testing.md

@@ -1,6 +1,6 @@
## Testing ## Testing
Using a different testing renderer (in a corresponding namespace `zterm.testing`) renderes without flushing to the screen, but keeps the corresponding `zterm.Cell` slice for comparison. The main question would rather be how to provide the expected value for the `zterm.Cell` slice. Using a different testing renderer (in a corresponding namespace `zterm.testing`) renders without flushing to the screen, but keeps the corresponding `zterm.Cell` slice for comparison. The main question would rather be how to provide the expected value for the `zterm.Cell` slice.
The test renderer shall be configured with a given size (as the corresponding terminal for the screen size will not be available). This serves two aspects: Firstly, `.resize` Event triggering and secondly, the rendering into a `zterm.Cell` slice with the provided size dimensions (for testing layout handling and rendering (i.e. of a scrollable element, etc.)). The test renderer shall be configured with a given size (as the corresponding terminal for the screen size will not be available). This serves two aspects: Firstly, `.resize` Event triggering and secondly, the rendering into a `zterm.Cell` slice with the provided size dimensions (for testing layout handling and rendering (i.e. of a scrollable element, etc.)).
@@ -69,7 +69,7 @@ test "test container against zon file" {
## Testing user interactivity ## Testing user interactivity
When testing with further user interaction the `zterm.testing.expectContainerScreen` function cannot be used. The function creates a *renderer*, *initializes* the provided container and renderes the *screen* for comparison. When testing with further user interaction the `zterm.testing.expectContainerScreen` function cannot be used. The function creates a *renderer*, *initializes* the provided container and renders the *screen* for comparison.
This is the implementation of `zterm.testing.expectContainerScreen`: This is the implementation of `zterm.testing.expectContainerScreen`:
@@ -89,7 +89,7 @@ pub fn expectContainerScreen(size: Size, container: *Container(event.SystemEvent
``` ```
> [!TIP] > [!TIP]
> Create serveral *checkpoint screens* that should be tested against when testing for user interaction. > Create several *checkpoint screens* that should be tested against when testing for user interaction.
For testing user interaction you need to provide the container with the corresponding *events* it should receive. This includes user key presses, mouse presses (with their corresponding location on the screen), etc. For example see the test for `Scrollable` elements, which create the scrollable `Container` renders it and tests the screen, then scrolls down, re-renders the `Container` to test and finally tries to scroll further down to test for scrolling down after reaching the end of the `Scrollable` element: For testing user interaction you need to provide the container with the corresponding *events* it should receive. This includes user key presses, mouse presses (with their corresponding location on the screen), etc. For example see the test for `Scrollable` elements, which create the scrollable `Container` renders it and tests the screen, then scrolls down, re-renders the `Container` to test and finally tries to scroll further down to test for scrolling down after reaching the end of the `Scrollable` element: