Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(10)

Side by Side Diff: sky/sdk/lib/base/node.dart

Issue 1211573003: Fill out some more documentation about building RenderBox subclasses. (Closed) Base URL: https://github.com/domokit/mojo.git@master
Patch Set: Created 5 years, 6 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View unified diff | Download patch
OLDNEW
1 // Copyright 2015 The Chromium Authors. All rights reserved. 1 // Copyright 2015 The Chromium Authors. All rights reserved.
2 // Use of this source code is governed by a BSD-style license that can be 2 // Use of this source code is governed by a BSD-style license that can be
3 // found in the LICENSE file. 3 // found in the LICENSE file.
4 4
5 class AbstractNode { 5 class AbstractNode {
6 6
7 // AbstractNode represents a node in a tree. 7 // AbstractNode represents a node in a tree.
8 // The AbstractNode protocol is as follows: 8 // The AbstractNode protocol is described in README.md.
9 // - When a subclass is changing the parent of a child, it should
10 // call either parent.adoptChild(child) or parent.dropChild(child)
11 // as appropriate. Subclasses should expose an API for
12 // manipulating the tree if you want to (e.g. a setter for a
13 // 'child' property, or an 'add()' method to manipulate a list).
14 // - You can see the current parent by querying 'parent'.
15 // - You can see the current attachment state by querying
16 // 'attached'. The root of any tree that is to be considered
17 // attached should be manually attached by calling 'attach()'.
18 // Other than that, don't call 'attach()' or 'detach()'. This is
19 // all managed automatically assuming you call the 'adoptChild()'
20 // and 'dropChild()' methods appropriately.
21 // - Subclasses that have children must override 'attach()' and
22 // 'detach()' as described below.
23 // - Nodes always have a 'depth' greater than their ancestors'.
24 // There's no guarantee regarding depth between siblings. The
25 // depth of a node is used to ensure that nodes are processed in
26 // depth order. The 'depth' of a child can be more than one
27 // greater than the 'depth' of the parent, because the 'depth'
28 // values are never decreased: all that matters is that it's
29 // greater than the parent. Consider a tree with a root node A, a
30 // child B, and a grandchild C. Initially, A will have 'depth' 0,
31 // B 'depth' 1, and C 'depth' 2. If C is moved to be a child of A,
32 // sibling of B, then the numbers won't change. C's 'depth' will
33 // still be 2. This is all managed automatically assuming you call
34 // 'adoptChild()' and 'dropChild()' appropriately.
35 9
36 int _depth = 0; 10 int _depth = 0;
37 int get depth => _depth; 11 int get depth => _depth;
38 void redepthChild(AbstractNode child) { // internal, do not call 12 void redepthChild(AbstractNode child) { // internal, do not call
39 assert(child._attached == _attached); 13 assert(child._attached == _attached);
40 if (child._depth <= _depth) { 14 if (child._depth <= _depth) {
41 child._depth = _depth + 1; 15 child._depth = _depth + 1;
42 child.redepthChildren(); 16 child.redepthChildren();
43 } 17 }
44 } 18 }
(...skipping 32 matching lines...) Expand 10 before | Expand all | Expand 10 after
77 void dropChild(AbstractNode child) { // only for use by subclasses 51 void dropChild(AbstractNode child) { // only for use by subclasses
78 assert(child != null); 52 assert(child != null);
79 assert(child._parent == this); 53 assert(child._parent == this);
80 assert(child.attached == attached); 54 assert(child.attached == attached);
81 child._parent = null; 55 child._parent = null;
82 if (attached) 56 if (attached)
83 child.detach(); 57 child.detach();
84 } 58 }
85 59
86 } 60 }
OLDNEW

Powered by Google App Engine
This is Rietveld 408576698