On Mon, 31 Aug 2026 20:06:55 GMT, Andy Goryachev <[email protected]> wrote:
>> Could we look at this from standpoint of _intent_? What is the application >> intent to have mismatched snapping? >> >> One possibility is some kind of transition/animation where the whole thing >> slides from one place to another, so the parent is snapped and the child >> might be not snapped for the duration of the transition. >> >> What could be the other scenarios? Especially those that involve unsnapped >> parent and snapped child, or when no movement is expected? > >> So my conclusion: > > or > 3. the boundaries passed to the snapped child(ren) are unsnapped, but the > internal boundaries are snapped > > > parent: > U-----------U > children: > U---S---S---U > > > (U = unsnapped, S = snapped) > Could we look at this from standpoint of _intent_? What is the application > intent to have mismatched snapping? I can't think of a good use case. There might be use cases for having entire sub-trees unsnapped, but not for switching a sub-subtree back to snapped (hence why I'm now of the opinion that we should treat snapping like we treat visible/disable, toggle it off and it is off for the entire subtree). > One possibility is some kind of transition/animation where the whole thing > slides from one place to another, so the parent is snapped and the child > might be not snapped for the duration of the transition. There is no reason to change the snap setting for animations; it will just create an awkward jump at the start/end of the animation. Animations work by using translations/scales/rotation etc, which are applied separately from the layout bounds. So if you have a button that must slide into place, just apply a translation and it will animate smoothly, with subpixel precision (and the eye won't notice the button temporarily being rendered at an unaligned X offset being perhaps slightly blurry unless you screenshot it mid animation). When the button settles into place, it will be exact pixel aligned again (when translation goes to 0). If you toggle snapToPixel at the last moment, the (entire) layout may jump slightly which will be visible to the naked eye, ruining your animation. > What could be the other scenarios? Especially those that involve unsnapped > parent and snapped child, or when no movement is expected? I can't think of any; even using unsnapped for an entire subtree (or using unsnapped at all) seems a stretch for anyone to ever need. Perhaps for "tiny" controls (close to pixel sized) where a full pixel more/less would ruin the look. Anything beyond a size where the user can interact with it (say 10+ pixels) seems ridiculous to use unsnapped. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2262#discussion_r3898014685
