On 07/12/2013 04:49 PM, Richard Bair wrote:
The thing is that in order to compute the layout correctly, you have to start
from the layout root.
I think where you start the computation from depends on what you are trying to do. I
think that "validate" or whatever we would call it would just be a convenient
wrapper that did whatever we consider the most common steps. But it seems like we should
expose the specific steps as well such that a developer can do what they want rather than
just what we provide.
So for example, most of the time I would assume these APIs would be called on
the layout root, naturally. So I am going to try to position the content of a
popup and need to measure the size of the content. This is easily and naturally
done by calling the APIs on the content root itself. On the other hand, even if
I were to measure the size of things on the layout root, once it is popped into
a scene which has a stylesheet that changes all of the CSS applied to that node
(or to a different parent which changes what CSS is applied) then my previous
measurements are toast anyway.
Is there any reason why I might want to measure a node independent of the
layout of its parent? If I have a Button in a StackPane, is there a time I
might want to measure the Button independent of the StackPane? I suppose so, if
for example I wanted to get snapshots of it at its min size, max size, and pref
size, regardless of what the layout container might do with the button. That
seems reasonable.
Yes, maybe. But that would require a completely different API.
The concept of layout roots is not documented well in the API ( we use the term
in few place, but never define it) and people would have to know how to
identify the layout root and also know that they need to start from the layout
root. Also, there's no way to check which Node is the layout root, although you
can identify it using managedProperty(), it's parent and/or sub scene.
Hmmm. OK, so today suppose I have a scene graph with a root node and someplace
down in the hierarchy is an unmanaged node. If I call layout() on the root
node, then it will layout everything except for the unmanaged node. If i wanted
to get a list of all the dirty layout roots, well, there is no public API to do
so.
After your change, the semantics of layout would be the same -- calling layout
on the root node isn't going to cause the unmanaged node to be laid out. So for
what Steve and I are proposing to make sense (just expose applyCSS), we also
have to expose either another method (layoutEverythingForTheLove) that will
force everything in the tree to be laid out, or we have to have another method
(getLayoutRoots) which will accumulate the layout roots so that you can then
call layout() on them all manually.
Actually, calling layout() on scene root will layout everything in the
root after my changes (as the flags must always be set up to the root,
so we can find the way to all dirty layout roots), currently this
doesn't work as the scene root doesn't know whether there are other
dirty layout roots in the scene. So if you have (Sub)Scene, you can just
call getRoot().layout() and everything should be laid-out correctly (if
you also called CSS before). But this would re-layout much more then is
needed for some specific Node.
The validate methods finds the layout root of the subtree where the Node
resides and does the layout from that layout root. If somebody needs more
precise control over layout, we can leave the layout() methods public. But I
expect people will be confused that simply calling the layout() on a Node will
not result in the layout they will see after pulse.
So, calling layout on this node's layout root isn't sufficient, it also has to
call layout on all layout roots that are beneath this node, right?
It is sufficient. In both implementations (current & the new one with
flags), layout() is called even on unmanaged children (and thus
layout-roots). But I think it stops on SubScenes.
BTW, I think we need to expose in API (not in this release) the concept of
layoutRoot, such that you can have a node be unmanaged which is not also a
layout root. Or did we do that already? Sometimes I just want a node to never
participate in layout. Ever. Because I am personally in charge of the node and
its children and either am using binding or am going to manage the position of
everything in that graph manually myself.
We don't have such concept currently. But we have Pane, which you can
override and have an empty layoutChildren().
-Martin
