|
|
@@ -66,7 +66,7 @@ This covers my thinking on how we will refactor `View` and the classes in the `V
|
|
|
* *TopLevel* - The v1 term used to describe a view that is both Modal and can have a MenuBar and/or StatusBar. I propose in v2 we deprecate the term `TopLevel` and instead use `Modal` to describe the same thing. We can completely get rid of the `TopLevel` class! I do not think `Modal` should be a class, but a property of `View` that can be set to `true` or `false`.
|
|
|
* *Window* - A View that, by default, has a `Border` and a `Title`.
|
|
|
* QUESTION: Why can't this just be a property on `View` (e.g. `View.Border = true`)? Why do we need a `Window` class at all in v2?
|
|
|
- * *Tile*, *Tiled*, *Tiling* (NOT IMPLEMENTED YET) - Refer to a form of `ComputedLayout` where SubViews of a `View` are visually arranged such that they abut each other and do not overlap. In a Tiled view arrangement, there is no Z-ordering. Borders that are drawn between the SubViews can optionally support resizing the SubViews (negating the need for `TileView`).
|
|
|
+ * *Tile*, *Tiled*, *Tiling* (NOT IMPLEMENTED YET) - Refer to a form of `ComputedLayout` where SubViews of a `View` are visually arranged such that they abut each other and do not overlap. In a Tiled view arrangement, Z-ordering only comes into play when a developer intentionally causes views to be aligned such that they overlap. Borders that are drawn between the SubViews can optionally support resizing the SubViews (negating the need for `TileView`).
|
|
|
* *Overlap*, *Overlapped*, *Overlapping* (NOT IMPLEMENTED YET) - Refers to a form of `ComputedLayout` where SubViews of a View are visually arranged such that their Frames overlap. In Overlap view arrangements there is a Z-axis (Z-order) in addition to the X and Y dimension. The Z-order indicates which Views are shown above other views.
|
|
|
|
|
|
## Focus
|
Tigger Kindel