I'm thinking applyCSS would just call impl_processCSS(true) and then we should work towards removing impl_processCSS(boolean) if possible, so that we're all just using applyCSS() all the time (once impl_processCSS(boolean) can be removed and all bugs sorted out, then we could just move impl_processCSS() guts into applyCSS, methinks).
Its OK with me if we make the transition over time. Richard On Jul 12, 2013, at 9:19 AM, David Grieve <david.gri...@oracle.com> wrote: > There is Node#impl_processCSS() that is the normal css processing path > (Scene#doCSSPass -> Node#processCSS -> Node#impl_processCSS() -> > CssStyleHelper#transitionToState) . > > impl_processCSS(boolean) was left in because it is a way of forcing the > reapply in cases where CSS was needed to be processed before the next pulse > but has become the panacea for covering up errors, i.e. "this doesn't display > right, try impl_processCSS(true)." > > On Jul 12, 2013, at 12:06 PM, Richard Bair <richard.b...@oracle.com> wrote: > >> My thought was that applyCSS could for now just call impl_processCSS(true) >> -- so it is "Thor's Hammer" and will just hammer everything to be updated. >> Not necessarily fast. Then in subsequent releases we could maybe tune it up. >> Do we *need* the boolean? I know it is sometimes false (TreeView, TableView, >> etc) and other times true. But is the "true" usage really needed or was it >> just to cover up errors we were seeing? I remember having done this but >> don't remember if it was truly needed or not? >> >> Richard >> >> On Jul 12, 2013, at 9:03 AM, David Grieve <david.gri...@oracle.com> wrote: >> >>> I hesitate to mention Node#impl_processCSS(boolean) which is very very >>> close to your notion of applyCss(); impl_processCSS(boolean) is a thorn in >>> my side, but is used in certain places in controls code to ensure CSS is >>> applied before layout in order to ascertain a node's dimensions. What it >>> does is walk up the tree to find the closest parent who's cssFlag is other >>> than clean and then calls processCSS from that node on down. The flag says >>> whether to simply update css or to reapply css (reapply involves figuring >>> out what styles apply to a node). >>> >>> impl_processCSS is also used by SceneBuilder. They created >>> https://javafx-jira.kenai.com/browse/RT-21206 asking to make >>> impl_processCSS(boolean) public. >>> >>> It should also be mentioned that pseudo-class state matters, including the >>> state of the parents, so depending on when you call applyStyle(), you might >>> get different results. The applyStyle() method can't really ignore >>> pseudo-class state since things like orientation (horizontal/vertical) are >>> kind of important. >>> >>> On Jul 12, 2013, at 11:32 AM, Richard Bair <richard.b...@oracle.com> wrote: >>> >>>>>> 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. >>>> >>>> In what way? Just having applyCSS exposed allows me to do this? >>>> >>>>>>> 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. >>>> >>>> If that's the case then it seems like all you need is applyCSS. Because >>>> from any node you get getScene().getRoot().layout(), or in the worst case >>>> walk up to the root and then fire off the applyCSS / layout. >>>> >>>> In this case, applyCSS becomes the essential API, and "validate" or >>>> whatever it would be called becomes the convenience API. In this case I >>>> would suggest adding the essential API and adding the convenience API >>>> subsequently when the pain is clearly felt and understood. >>>> >>>> Richard >>> >> >
