On Tue, 27 Apr 2021 16:30:52 GMT, mstr2
wrote:
> I think you're right that the same test could also be added for
> TreeTableView, and that the test should probably cover the entirety of the
> change notification. However, my preference is to not create a test that
> duplicates all aspects of
On Tue, 27 Apr 2021 19:10:29 GMT, mstr2
wrote:
> > The only very minor drawback is that it requires to update the Eclipse
> > classpath to add-exports for the base testing package (not a big deal).
>
> Can you share where specifically this needs to be added?
Could do, but if you aren't using
On Tue, 27 Apr 2021 16:30:52 GMT, mstr2
wrote:
> The only very minor drawback is that it requires to update the Eclipse
> classpath to add-exports for the base testing package (not a big deal).
Can you share where specifically this needs to be added?
-
PR:
On Tue, 27 Apr 2021 10:18:24 GMT, Jeanette Winzenburg
wrote:
> A couple of notes to your test - my personal preferences:
>
> * they should cover all changes, that is test both Tree- and TreeTableView
> * if possible, have a test that really cover the report: here that would be
> throwing a
On Sun, 25 Apr 2021 15:36:49 GMT, mstr2
wrote:
>
>
> You're right that removing `ControlUtils.reducingChange` is enough to solve
> the problem. Maybe the method was created because it might be confusing that,
> while the indices are often not adjacent, they _are_ (as you correctly say)
>
On Sun, 25 Apr 2021 15:35:58 GMT, mstr2
wrote:
>> This PR fixes the implementation of `ControlUtils.reducingChange`, which
>> incorrectly computed adjacent removed indices, thus resulting in incorrect
>> removal notifications.
>>
>> Since there were no unit tests for this method, I also
> This PR fixes the implementation of `ControlUtils.reducingChange`, which
> incorrectly computed adjacent removed indices, thus resulting in incorrect
> removal notifications.
>
> Since there were no unit tests for this method, I also added a bunch of tests.
>
> After applying this fix, I can
