60177a71ab
This introduces a GlobalKey registry so that you can tell when a key has gone away (so you can unfocus dead dialogs). Also I added an assert that you're not calling setState() during a build. It turns out that doing so means you have a bug, because since you're dirty already (you're building), you won't get rebuilt. The focus code itself is gnarly. It uses a Component and an internal Inherited TagNode to manage the focus state, and does crazy things like updating its state during build to pretend retroactively that it was built with some other state, once someone asks for focus the first time (i.e. the first time it's examined, so you can't tell that it was in a different state before). It does this so that it can autofocus controls which otherwise wouldn't be focused. This moves all the focus management into Navigator and showDialog(), so the complexity is all buried deep and not visible to apps, hopefully. To do something like two tabs that each have an Input widget that needs to be focused when you switch panes, you'd need to have two Focus objects, one in each tab, and you need to set their autofocus to true (maybe that should be the default?).
SKY SDK
Sky and Sky's SDK are designed as layered frameworks, where each layer depends on the ones below it but could be replaced wholesale.
The bottom-most layer is the Sky Platform, which is exposed to Dart
code as various dart: packages,
including dart:sky.
The base/ directory contains libraries that extend these core APIs to provide base classes for tree structures (base/node.dart), hit testing (base/hit_test.dart), debugging (base/debug.dart), and task scheduling (base/scheduler.dart).
Above this are the files in the painting/ directory, which provide APIs related to drawing graphics, and in the animation/ directory, which provide core primitives for animating values.
Layout primitives are provided in the next layer, found in the
rendering/ directory. They use dart:sky and the
APIs exposed in painting/ to provide a retained-mode layout and
rendering model for applications or documents.
Widgets are provided by the files in the widgets/ directory, using a reactive framework. They use data given in the theme/ directory to select styles consistent with Material Design.
Text input widgets are layered on this mechanism and can be found in the editing/ directory.
Alongside the above is the mojo/ directory, which contains anything that uses the Mojo IPC mechanism, typically as part of wrapping host operating system features. Some of those Host APIs are implemented in the host system's preferred language.
Here is a diagram summarising all this:
+-----------------------------+ ------
| YOUR APP |
| +--------------------+--+
| | editing/ | |
| +--+-------------------++ |
| | widgets/ (theme/) | |
| ++---------------------++ | Dart
| | rendering/ | |
+-+---------+------------+ |
| painting/ | animation/ | |
+---------------+--------+ |
| base/ | mojo/ |
+------------+--+-+----+------+ -------
| dart:sky | | | Host |
+--------+---+ | | APIs | C++
| Skia | Dart | +------+ ObjC
+--------+--------+ | Java
| Mojo |
+-----------------------------+ -------
| Host Operating System | C/C++
+-----------------------------+ -------
TODO(ianh): document dart:sky and the Host APIs somewhere
Sky Engine API
The Sky engine API provides efficient, immutable wrappers for common Skia C++ types, notably Color, Point, and Rect. Because these wrappers are immutable, they are suitable for storage in final member variables of widget classes. More complex Skia wrappers such as Paint and RRect are mutable, to more closely match the Skia APIs. We recommend constructing wrappers for complex Skia classes dynamically during the painting phase based on the underlying state of the widget.