On Tue, 20 Oct 2026 18:21:27 GMT, Andy Goryachev <[email protected]> wrote:
>>> I do have a solution for this, that I use for my own programs. They're >>> basically a different kind of property that allows the owner of the >>> property (ie. the control, table, whatever) to control when listeners fire >>> (something we see already in some areas of FX where properties are >>> "customized" to delay firing, but that's usually manual and not coordinated >>> across multiple properties). >> >> I'm all ears. A solution to this problem in JavaFX would be great. >> Yeah JavaFX already uses this mechanism for e.g. `focusProperty` and it >> makes sense. >> >>> For example, if I need to change 3 properties, but they're all related >>> (let's say x,y,z) I can change all three, and only at the end of my changes >>> have the listeners fire. >> >> This is exactly what we need. >> >>> This is basically a general problem for any program that allows arbitrary >>> callbacks (which in JavaFX are often hidden in events/listeners). Calling >>> any callback while you're structure isn't in a fully consistent state is >>> problematic if your code must continue working no matter what silly things >>> the user might do there. >> >>> I think that's really one of the next areas (after correct old/new values >>> which was merged now) that JavaFX may see huge benefits from, especially >>> for insanely complex controls like TableView. >> >> I agree, and yes this will really be a huge benefit! >> It is also not just us who think this might need some improvements. >> I believe @mstr2 as well did write and drafted some improvements to the >> mailing list years ago as far as I can remember. >> >>> And even worse than that: a complete waste of time to fix, as you spend a >>> ton of code on these edge cases, code paths that are near impossible to >>> exercise and then almost never occur in the wild but still must be taken >>> into account just in case. Better to address the root cause, and then not >>> only being able to write the code much more directly, but also being able >>> to proof that it is correct in all cases as there no longer is user >>> callback interference. >> >>> I like to think that current JavaFX properties in complex controls is like >>> writing a database program without having transactions. Sure, you may be >>> able to catch all possible problems and compensate for the lack of >>> transactions, but we're talking about a ton of code for situations that >>> shouldn't even occur in the first place. >> >> 100% agree. This is all visible in my current CSS 'saga' (bunch of PRs just >> to fix one flaw). > >> This is basically a general problem for any program that allows arbitrary >> callbacks (which in JavaFX are often hidden in events/listeners). Calling >> any callback while you're structure isn't in a fully consistent state is >> problematic if your code must continue working no matter what > > If I understand this correctly, this is not a problem per se, as long as the > process converges and has no loops. In other words, a single property change > might trigger a cascade of updates which must eventually settle. > > Once settled, the `layoutChildren()` does the layout and updates the scene > graph. > > Perhaps what we need is to detect the loops? Or am I missing something? > > -- > > Another, related, scenario is when the update cascade requires explicit > layout pass (or N passes, as it happened in RichTextArea with N=2). It is > possible to let the multiple pulses do their job, at the risk of flicker or > perpetual layout going on (I've seen that). I think it is better to > explicitly acknowledge these cases and design for them. Layout is already special, it is done once per frame at most, and the deferral system (`requestLayout`) protects somewhat against the things that callbacks can do (and even then there is documentation stating you shouldn't be binding or modifying certain layout specific properties). Properties that defer calling their listeners already exist, because callbacks would interfere with whatever they're trying to achieve. Most user callbacks won't interfere, but almost any group of two properties that are being manipulated "as part of a whole" can be interfered with with a specially crafted listener on one of them. Loop detection only buys you that you notice that the properties are inconsistent (like the warning in #1081) but there's no route to fix it as any fix attempt can be thwarted by a listener user callback. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/2347#discussion_r4336074936
