Overview
Comment: | imgui design notes additions |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | trunk |
Files: | files | file ages | folders |
SHA1: |
1e328bcd882f7319618f5ef3e750a461 |
User & Date: | spaskalev on 2015-09-22 09:14:47 |
Other Links: | manifest | tags |
Context
2015-09-22
| ||
09:14 | imgui design notes additions Leaf check-in: 1e328bcd88 user: spaskalev tags: trunk | |
06:54 | added design notes for imgui check-in: 4d1ed64397 user: spaskalev tags: trunk | |
Changes
Modified src/0dev.org/imgui/design.txt from [128d0bd137] to [352165b2a4].
1 2 3 4 | Design of an immediate graphical user interface api with managed layouts Terms: | | > > | > > > > > > > | 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 33 34 35 36 37 38 39 40 41 | Design of an immediate graphical user interface api with managed layouts Terms: 1. Canvas - a drawing area 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(last 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 + does not imply a dependency on the layout, the UI drawing needs just a starting point * 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 - puts a dependency on the layout The first strategy is definatelly more sound and neatly allows for a layout-aware tracker to handle the locations. \---------------------------------- 3. I would like to enhance drawing functions with additional behavior (e.g. layout trackers, styling, etc) |
Modified src/0dev.org/imgui/imgui.go from [8340e5f08a] to [6ffb33222b].
1 2 3 4 5 6 7 8 9 10 | package imgui // Defines a point in a top-left coordinate system type Point struct { X, Y uint16 // might revisit type for bigger resolutions } type Layout interface { // Advances the layout and returns a starting point // for an element based on the last ending point. | | | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | package imgui // Defines a point in a top-left coordinate system type Point struct { X, Y uint16 // might revisit type for bigger resolutions } type Layout interface { // Advances the layout and returns a starting point // for an element based on the last ending point. Next(last Point) Point } // Groups UI drawing routines type Canvas interface { Layout // Draws a string Label(string) |
︙ | ︙ |