On Tue, 3 Mar 2026 13:46:10 GMT, Kevin Rushforth <[email protected]> wrote:
>>> `AsciiArtParser` seems like a fun toot: the main benefit of using it is >>> that it requires a graphical representation of the desired outcome, which >>> might be nice. >>> >>> This benefit is also a drawback: these diagrams are difficult to create and >>> maintain. Plus, we would need to maintain the parser itself as a part of >>> javafx code base. >> >> The parser is purposely very simplistic and unoptimized, as it is only need >> serve its purpose of verifying layout. I don't expect it to need much >> maintenance (it's been this way for a few years already). >> >> The diagrams are IMHO quite easy to make, and visually show you exactly >> where components are and how they relate to each other. What was before a >> jumble of numbers, often incomplete, and hard to grasp (and different every >> time in FX layout tests) is now a simple visual diagram where things like >> sums and positions are always tested fully with clear error messages when >> they deviate. >> >>> One possible alternative is to forgo the graphical aspect of it and simply >>> describe the expected layout in form of a CSV-like table (or a github-like >>> table), for example: >>> >>> ``` >>> Location | WxH | Margins >>> ---------|--------|-------- >>> |10 x 5 | >>> |200 x 5 | 5 5 5 0 >>> ``` >> >> This won't really show you the relation and positions of components, and >> will quickly become a jumble of numbers just like the standard asserts >> already are. I specifically wrote this parser a few years ago to test a >> rather difficult layout container of my own, allowing me to create easy to >> grasp tests for various complex situations. It's not limited in any way, and >> can even be used to test nested container layouts to check things like how a >> VBox behaves nested in an HBox nested in a BorderPane, to ensure even >> interactions between different containers can be verified. >> >> I think it really is a very useful tool in the toolkit, and I think one that >> will encourage more and better tests for FX controls. > >> The parser is purposely very simplistic and unoptimized, as it is only need >> serve its purpose of verifying layout. I don't expect it to need much >> maintenance (it's been this way for a few years already). > > If it were in the product I'd have the same concern Andy raised, but since it > is a test utility, it seems fine to me (in concept; I didn't review it in > detail). > @kevinrushforth @johanvos I think this may be a good candidate for a > backport. Reason: it resolves a regression introduced in JFX 25, and the fix > is small and isolated. OK with me for jfx26u. Johan can answer for jfx25u. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2077#issuecomment-3998391634
