Check-in [4d1ed64397]
Overview
SHA1:4d1ed64397d9fd31366ef0c457328729abc4ab11
Date: 2015-09-22 06:54:01
User: spaskalev
Comment:added design notes for imgui
Timelines: family | ancestors | descendants | both | trunk
Downloads: Tarball | ZIP archive
Other Links: files | file ages | folders | manifest
Tags And Properties
Context
2015-09-22
09:14
[1e328bcd88] Leaf: imgui design notes additions (user: spaskalev, tags: trunk)
06:54
[4d1ed64397] added design notes for imgui (user: spaskalev, tags: trunk)
2015-09-09
22:22
[bc1a46b4d9] initial imgui api ideas (user: spaskalev, tags: trunk)
Changes

Added src/0dev.org/imgui/design.txt version [128d0bd137].

































































>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Design of an immediate graphical user interface api with managed layouts

Terms:

1. Canvas - a drawing area with a managed layout

User stories

1. I would like to call UI-rendering functions without specifying dimensions and locations
2. I would like to call custom UI-rendering functions while specifying dimensions and locations

Story 2 needs a way to get a proper starting location or a bounding box If 1 is in place.

Consider the single method Layout interface:

type Layout interface {
	// Advances the layout and returns a starting point
	// for an element based on the last ending point.
	Next(Point) Point
}

Story 1 necessitates that library-aware UI-rendering functions acquire their starting locations
on their own. This allows for the following two approaches (more are possible of course)

* Store the ending point of the last element. New calls can get it and pass it to the layout
  + does not advance the layout unless required, saving cpu

* Store the next starting point by calling Next() at the end of the element drawing routine.
The next drawing can continue from it.
  - advancing the layout costs cpu
  - the user might want an out of layer render