interesting
/
libui
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

More lifetimes.md work.

This commit is contained in:
Pietro Gagliardi 2015-04-19 17:12:28 -04:00
parent c2c03949d2
commit 883776b89b
1 changed files with 6 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
docs/lifetimes.md
View File

@ -12,7 +12,7 @@ TODO complain loudly if Destroying a control with a parent
The rules for lifetimes are simple: The rules for lifetimes are simple:
- Removing a control from a container (for instance, with `uiBoxDelete()` or `uiTabDeletePage()`) does NOT destroy the control. - Removing a control from a container (for instance, with `uiBoxDelete()` or `uiTabDeletePage()`) does NOT destroy the control.
- Destroying a container (`uiWindowDestroy()`, `uiControlDestroy()` on a uiBox or uiTab, et.c) WILL destroy children. - Destroying a container (`uiWindowDestroy()`, `uiControlDestroy()` on a uiBox or uiTab, etc.) WILL destroy children.
- Otherwise, a control stays alive. - Otherwise, a control stays alive.
- It is an error to destroy a control while it is part of a container. - It is an error to destroy a control while it is part of a container.
- It is an error to add a control to more than one container at once. - It is an error to add a control to more than one container at once.
@ -23,7 +23,9 @@ Currently, breaking these rules results in undefined behavior. Error checks will
Note that control implementations generally don't need to worry about backend-specific information; these are handled by the backends's convenience functions. If you bypass those, however, you *will* need to worry. Note that control implementations generally don't need to worry about backend-specific information; these are handled by the backends's convenience functions. If you bypass those, however, you *will* need to worry.
### Backend-Agnostic (uiBox, uiGrid) ### General
### Containers (uiBox, uiGrid)
### Windows ### Windows
@ -39,6 +41,8 @@ The destruction process is simple:
3. Any child windows are destroyed. 3. Any child windows are destroyed.
4. The window receives `WM_NCDESTROY`. 4. The window receives `WM_NCDESTROY`.
TODO write this
### Unix ### Unix
All GtkWidgets are initially created "floating" (referenceless but unowned). When adding to a GtkContainer, the reference count is increased. When removing from a GtkContainer, the reference count is decreased. When the reference count drops back to zero, the widget is destroyed. Since containers are also widgets, when a container is destroyed, its children are removed (TODO verify this). All GtkWidgets are initially created "floating" (referenceless but unowned). When adding to a GtkContainer, the reference count is increased. When removing from a GtkContainer, the reference count is decreased. When the reference count drops back to zero, the widget is destroyed. Since containers are also widgets, when a container is destroyed, its children are removed (TODO verify this).