From f097a4b4dafbf2c8002a64c59479e8466c113c6f Mon Sep 17 00:00:00 2001 From: Yves Biener Date: Sat, 22 Feb 2025 11:01:14 +0100 Subject: [PATCH] wip: `Container` and `Element` documentation brain-dump --- Containers.md | 8 ++++++++ Elements.md | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 41 insertions(+) create mode 100644 Containers.md diff --git a/Containers.md b/Containers.md new file mode 100644 index 0000000..b0dcfcc --- /dev/null +++ b/Containers.md @@ -0,0 +1,8 @@ +# [TODO] Containers + +Decorations should respect the layout and the viewport accordingly. This means +that scrollbars are always visible (except there is no need to have a scrollbar) +irrelevant depending on the size of the content. The rectangle apply to all +cells of the content (and may be overwritten by child elements contents). +The border of an element should be around independent of the scrolling of the +contents, just like padding. diff --git a/Elements.md b/Elements.md index bf475ca..47932b0 100644 --- a/Elements.md +++ b/Elements.md @@ -8,6 +8,39 @@ library should instead provide small examples to show how you can implement such user fields yourself and connect them using your own event system loops to communicate with other `Container`s and/or `Element`s. +### User specific event handling and content rendering + +For interactions controlled by the user each container can use an `Element` +interface which contains functions which are called by the `Container` +during event handling (i.e. `fn handle(..)`) and during rendering (i.e. `fn +content(..)`) to provide user specific content and user interaction. The +`Element` may be stateful, but may also be stateless and then be re-used in +multiple different `Container`s. + +Composing multiple `Element`s currently requires the implementation of a wrapper +which contains the `Element`s that need to be handled (should work pretty well +for stateless `Element`s). Such *stateless* `Element`s may be provided by this +library. + ### Scrollable +Contents that is scrollable should be done *virtually* through the contents of +the `Container`. This means each container contents implements scrolling for +itself if required. + +This still has one issue: Layout of child elements that are already too large +(i.e. or become too small). The library could provide automatic rendering of a +scrollbar given the right parameters however. The scrolling input action would +then also be implemented by the user. + +Open questions are regarding the sizing options (i.e. how is the size of a +`Container` actually controlled?, how should it be controlled?, etc.). There +should be support for the child elements to provide some kind of 'list' +functionality built-in. + +**REMINDER**: (mostly for myself) The library should be and remain simple. This +means that some code for using the library may be duplicated, but this is not +the main goal. Others may provide more re-usable code snippets that build on top +of this library instead. + ### Advanced usage