On Mon, 5 Feb 2024 16:02:46 GMT, Andy Goryachev <ango...@openjdk.org> wrote:
> > , in order to "not break things" we would have to introduce an API to users > > to be able to control the number of rows they want to be taken into account. > > I think the UI "breaking itself" is much worse than us changing the (buggy) > behavior. The user gains very little if the UI locks up for several seconds > (or minutes) trying to size every row. I don't agree. Our production application usually loads 200 rows and lets the user load as many more rows as they see fit. It also provides a "fit all columns" function which will fit all columns of the table. Users are fine with a few seconds of blockage if they have loaded thousands of rows. But if the "fit all columns" function will no longer work, they will report a bug which I will not be able to fix, if JavaFX suddenly refuses to iterate over all the rows as it does now. So maybe we should: * Provide an API that let's the client specify how many rows should be taken into account * Make resizeColumnToFitContent available for clients > > At the same time the user might simply double click on the header again (or > better, just resize the offending column like they used to do since time > immemorial) once a wide cell comes into view. > > Basically, I don't think the new API is required in this particular case; I > think it's a bug and it should either size the visible rows or (visible + > some margin). Of course, there is one more operation which guarantees a lock > up with large models - sorting. There is no easy solution for sorting, and > that's where we _might_ need new APIs. And it is a totally separate issue. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1358#issuecomment-1928861769
