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

fix: correct quotation for tip block

Yves Biener
2025-02-22 11:02:59 +01:00
parent f097a4b4da
commit 4cd6cf1d9b
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
Design.md

@@ -14,7 +14,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.
> [!TIPS] > [!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 aways 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.