On Tue, 3 Jan 2023 19:02:20 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
>> The current CONSTRAINED_RESIZE_POLICY has a number of issues as explained in >> [JDK-8292810](https://bugs.openjdk.org/browse/JDK-8292810). >> >> We propose to address all these issues by replacing the old column resize >> algorithm with a different one, which not only honors all the constraints >> when resizing, but also provides 4 different resize modes similar to >> JTable's. The new implementation brings changes to the public API for >> Tree/TableView and ResizeFeaturesBase classes. Specifically: >> >> - create a public abstract javafx.scene.control.ConstrainedColumnResizeBase >> class >> - provide an out-of-the box implementation via >> javafx.scene.control.ConstrainedColumnResize class, offeting 4 resize modes: >> AUTO_RESIZE_NEXT_COLUMN, AUTO_RESIZE_SUBSEQUENT_COLUMNS, >> AUTO_RESIZE_LAST_COLUMN, AUTO_RESIZE_ALL_COLUMNS >> - add corresponding public static constants to Tree/TableView >> - make Tree/TableView.CONSTRAINED_RESIZE_POLICY an alias to >> AUTO_RESIZE_SUBSEQUENT_COLUMNS (a slight behavioral change - discuss) >> - add getContentWidth() and setColumnWidth(TableColumnBase<S,?> col, double >> width) methods to ResizeFeatureBase >> - suppress the horizontal scroll bar when resize policy is instanceof >> ConstrainedColumnResizeBase >> - update javadoc >> >> >> Notes >> >> 1. The current resize policies' toString() methods return >> "unconstrained-resize" and "constrained-resize", used by the skin base to >> set a pseudostate. All constrained policies that extend >> ConstrainedColumnResizeBase will return "constrained-resize" value. >> 2. The reason an abstract class ( ConstrainedColumnResizeBase) was chosen >> instead of a marker interface is exactly for its toString() method which >> supplies "constrained-resize" value. The implementors might choose to use a >> different value, however they must ensure the stylesheet contains the same >> adjustments for the new policy as those made in modena.css for >> "constrained-resize" value. > > Andy Goryachev has updated the pull request incrementally with two additional > commits since the last revision: > > - 2023 > - 2023 The Windows HiDPI behavior (on my system with a screen scale of 1.25) is _much_ better with the latest version. With a policy of NEXT or LAST, the divider tracks the mouse cursor as I would expect. With a policy of FLEX_NEXT or FLEX_LAST, it tracks until the first (or last) column being resized hits its minimum and it switches to another column. Similarly, with a policy of SUBSEQUENT, it doesn't quite track as expected when one of the columns gets small (i.e., close to its minimum). This might just be error accumulation. It seems like a minor problem. I am seeing a new behavior, unrelated to HiDPI, that I don't recall seeing before. The "flex" policies will start out correctly taking the extra space from the next (or last) column, then unexpectedly switch to a different column, then later switch back to the next (or last) column. As far as I can tell, it only happens when the window is resized from its initial size. The easiest way to see this is: 1. Resize the window such that the width is larger 2. Resize the FX split pane making the table wider 3. Select "Data" -> "pref only" 4. Select "Policy" -> "AUTO_RESIZE_FLEX_LAST_COLUMN" 5. Drag the divider between "C1" and "C2" to the right It will start out taking the space needed to make C1 larger from C4 (as expected), then switch to one of C2 or C3 before C4 has resized to its minimum, then after a while, it will switch back to C4 until it has hit its minimum. This happens on both Mac and Windows. ------------- PR: https://git.openjdk.org/jfx/pull/897
