I've created a small sample app (a screenshot is available in the GitHub PR discussion at https://github.com/openjdk/jfx/pull/433), and it seems to me that, while understanding the intricacies of isTextBaseline and isPrefBaseline might be a bit tricky, from an application developer's perspective it seems to "just work" in most cases that I've tried so far. However, I think the documentation still needs to be improved when the concepts settle.
As to your questions: it is true that isTextBaseline generally propagates up the scene graph. Parent::isTextBaseline() reports true if, when computing its own baseline offset, it selects a child that reports isTextBaseline()==true as the baseline source. However, even when text baseline children are available, the selected child might not be a text baseline node if prefBaseline=true was specified on a non-text child node to override the default selection. I think isTextBaseline could reasonably be a read-only property, the performance impact is probably negligible if the property is only initialized when it is actually accessed. Am Fr., 16. Apr. 2021 um 19:08 Uhr schrieb Kevin Rushforth <kevin.rushfo...@oracle.com>: > > Good, since these are the sort of behavioral changes we almost always > avoid. That change in the default behavior likely would not have been > approved. > > As for the rest, I'll need some time to fully understand the impact of > the proposed behavior for propagating isTextBaseline up the tree, and > how that interacts with prefBaseline. It seem like it might be tricky to > document and for app developers to understand all the ramifications. > > A couple questions: First, I presume you are only proposing to propagate > isTextBaseline up the scene graph, meaning that all parents would report > textBaseline == true if that parent is a text baseline node (e.g., > Labeled, TextFlow) or if any descendant is? Second, given that > isTextBaseline is not immutable, have you considered whether it should > be a read-only property, so an application could listen for changes or > bind to it? There would likely be a performance trade-off in making it a > property. > > -- Kevin
