On Fri, 12 May 2023 18:40:20 GMT, John Hendrikx <jhendr...@openjdk.org> wrote:
>>> I think once there is an unsnapped parent, all children should probably >>> also be unsnapped (ie. the property should work like the visible property; >>> if I turn it off for one parent, all children become invisible/unsnapped). >> >> One complication with this is that the `snapToPixel` property is on >> `Region`, so `Group` (or any other `Parent` that isn't a `Region`) doesn't >> have that property. What you describe _might_ be OK as long as you ignore >> any parent that isn't a `Region` when asking the question "are all my >> ancestors have `snapToPixel`". >> >>> Basically, there are three strategies for children when dealing with an >>> unsnapped parent: >>> >>> * Just do snapping as normal (JavaFX currently) and when the parent >>> translation is added, all final positions will be shifted by an unsnapped >>> amount resulting in all calculations (even though they used snapping logic) >>> to be in the "wrong" positions >> >> Right. If a non-snap-to-pixel ancestor lays out it children, then all bets >> are off. Absent a compelling reason to change it, this seems like a >> reasonable default (perhaps it should be documented better). >> >>> * Ignore snapping when a parent is unsnapped and use standard calculations >> >> A change to do this _might_ be OK, with the caveat I mentioned above about >> non-Region parents, but this would need careful analysis. As part of this, I >> would want to understand the motivation for doing this (i.e., what is the >> benefit?). >> >>> * Somehow try to resnap content taking the parent misalignment into >>> account; this is going to cause visual artifacts as the parent is moved, >>> and requires some kind of flexible border >> >> Yeah, this doesn't seems like a good idea. >> >> If you want to explore this further, you could file a new RFE to consider >> making a change. > > @kevinrushforth it probably isn't worth pursuing a change in the child/parent > snapping logic right now, at least not without some compelling case. First I > think snapping is rarely disabled (I never have, despite working on graphics > heavy JavaFX applications). Second, one can already get the (possibly more) > desired situation by taking care all children are unsnapped as well. I agree with the consensus here. And same as @hjohn, I actually also never disabled snapping. There was never usecase where I needed to do so (And I worked on a lot of UI related things, including creating custom components of all kind). > Right. If a non-snap-to-pixel ancestor lays out it children, then all bets > are off. Absent a compelling reason to change it, this seems like a > reasonable default (perhaps it should be documented better). I agree here.The defaultis fine, and it's hard to say what would be a better default 'setting' here (if there really is a better way). Does a developer really expect that all children of a unsnapped node are unsnapped as well? Or is there a usecase where you don't want this? It's hard to answer, so as written above, the default seems fine and logicial. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/910#discussion_r1192780661
