rummagings about gui design

gui.txt

An UI has several parts:

1. The "Layout": Defines the space each control takes. "This button is 32x32 px and is located in 100,100"
2. The "Function": what happens when a control is used. "This needs to happen when this button is pressed"
3. The "Skin": how each control is displayed. "This button, with this state, is a red circle"
4. Bells and whistles: Things like state animations, or playing a sound when a button is hovered.
5. Current focus.
6. A way to handle input: Move focus to next item. "There is a pointer pressing on this position".

Problems:
1. What happens with the layout if the gui "moves around", or "changes size"? Is that even a good idea in the first place?
   What about different resolutions? How does this affect Layout sizes?
2. Is the "Function" really different from "Bells and whistles", though? Should "onpress" be on a different category than "on hover"?
3. Someone has to pass state to the draw functions. "This button is hovered". "This button is focused". Also, what happens
   with things like animations? Can the skin alter the layout, or is it off-bounds? How do we customize controls (i.e. make the exit button red insteady of the default gray)?
4. Who stores the state "this button is playing this animation"? Internal state in the skin?
5. The fact that there is a "previous" and "next" means that there needs to be an "order". 
   Is the current focus stored in the "gui" level?
6. Some of these inputs will affect a single control, while others will affect the whole thing.
7. There is also the problem of state:
   * Some state is clearly "important": This button has been pressed. (Even for that, you need to detect click and release, and that means extra state)
   * Some state is clearly "not important": Fluff stuff like "This button is animating because the user is not hovering it any more"
   * But other state is "only semi-important": Knowking that a tab is active, or a dropdown is open, is important, but not as much (or as final) as pressing a button.
   Someone needs to handle this.
8. In an immediate gui, the state (at least the important and semi-important) needs to be stored in the gui, and each control needs a unique ID from which its state can be retrieved.
   The unimportant state could be stored in the skin, but it would have to make the same thing: getting the control state using an ID from the gui. I'd rather do the ID thing only in one place.
9. Special effects such as animations need their own "update(dt)". This probably goes into the skin. So it needs at least a draw function and a update function.

Possible solutions / Directions

1. In order to be immediate and at the same time detect state change (i.e. a button was pressed and now it is released), there needs to be an "id" per control
2. There needs to be a grid abstraction. Because grids are awesome.
3. Each control needs its own set of ltwh in order to allow for "mobile controls"
4. Putting 2) an 3) together, the rectangle abstraction needs to return rectangles.
5. Controls: Button, slider, ???
7. .hover, .focus, .blur, .press, .release statuse for regular controls
8. skin gets the state so it can do bells and wistles. It also gets an `update(dt, control)` call for animations and such.