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.
> [!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.

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] built-in single line
- [ ] 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)
- [x] Radio Button (`bool`'s)
- [ ] 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] `Scrollable` test cases containing inclusion of test creation containing user interaction (i.e. mouse scrolling)
- [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:
- [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
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.)).
@@ -69,7 +69,7 @@ test "test container against zon file" {
## 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`:
@@ -89,7 +89,7 @@ pub fn expectContainerScreen(size: Size, container: *Container(event.SystemEvent
```
> [!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: