From 12788b9c2120e38877d34abfb4610b434c906c8f Mon Sep 17 00:00:00 2001 From: omar Date: Mon, 15 Feb 2021 12:34:00 +0100 Subject: [PATCH] Updated About the IMGUI paradigm (markdown) --- About-the-IMGUI-paradigm.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/About-the-IMGUI-paradigm.md b/About-the-IMGUI-paradigm.md index b6e47ce..90deb48 100644 --- a/About-the-IMGUI-paradigm.md +++ b/About-the-IMGUI-paradigm.md @@ -39,8 +39,8 @@ The existence of those two terms effectively has hindered both discussions and r This is in comparison with typical RMGUI ("retained-mode UI") which: -- Often have the app/programmer to retain lots of artifacts from the UI library (e.g. create objects, maintain references). -- Often have the UI library retain app/programmer data in widgets, requiring synchronization mechanisms. +- Often have the app/programmer retain artifacts from the UI library (e.g. create objects, maintain references). +- Often have the UI library retain app/programmer data in UI widgets, requiring synchronization mechanisms. What it doesn't stands for: @@ -54,7 +54,7 @@ What it doesn't stands for: - IMGUI does not means that layout features are limited. - IMGUI does not means that there is a single pass flow. -TODO: Each of those points should be explained with a paragraph. We could also describe how common UI libraries (of all types) stand on a given axis. +TODO: Each of those points should be explained with a paragraph. We could also describe how common UI libraries (of all types) stand on a given axis. We could also described less explored paths and envision what new UI libraries could do. ### Vurtun's writeup