On Sat, 24 Apr 2021 04:11:28 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 metho
the correct index.
>
> `SelectedItemsReadOnlyObservableList` doesn't apply removals to
> `itemsRefList`, which means that subsequent removals will refer to the wrong
> index when retrieving the removed elements. This PR fixes the calculation of
> the current index.
mstr2 h
On Tue, 27 Apr 2021 14:12:23 GMT, Kevin Rushforth wrote:
> I reread the description of
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228) and it
> describes multiple problems. Are all of them addressed by this PR?
This PR lists the following issues:
1. The SelectedItems list
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with one additional commit
since the last revisi
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 Fri, 2 Apr 2021 19:47:30 GMT, mstr2
wrote:
> This PR fixes incorrect parsing of mnemonic symbols in the following cases:
> 1. an escaped double underscore incorrectly shows up as a double underscore
> in displayed text
> 2. an extended mnemonic incorrectly removes a part of a
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 no longer
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with one additional commit
since the last revision:
Use M
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 Sat, 24 Apr 2021 18:29:47 GMT, Kevin Rushforth wrote:
> Also, if you could explain the logic changes a bit, that would be helpful.
Here's my guess what the original implementation tried to accomplish:
...
while (endPos < removed.size()) {
if (removed.get(startPos) ==
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with two additional commits
since the last revision:
-
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
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with two additional commits
since the last r
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with one additional commit
since the last revision:
Added t
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with two additional commits
since the last revision:
- Re
On Mon, 3 May 2021 20:51:13 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
On Mon, 3 May 2021 09:41:44 GMT, Ambarish Rapte wrote:
>> mstr2 has updated the pull request incrementally with one additional commit
>> since the last revision:
>>
>> Use MockListObserver
>
> modules/javafx.controls/src/test/java/test/javafx/scene/control/
On Wed, 28 Apr 2021 10:50:29 GMT, Jeanette Winzenburg
wrote:
> Hmm .. doesn't seem to be throwing since fx9 as of Ajit's first comment, in
> fact can't reproduce it with current fx16dev, neither with nor without this PR
You're right, somehow I was under the impression it did throw. Maybe I
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with one additional commit
since the last revision:
Fixed
lying this fix, I can no longer reproduce
> [JDK-8189354](https://bugs.openjdk.java.net/browse/JDK-8189354) and
> [JDK-8189228](https://bugs.openjdk.java.net/browse/JDK-8189228).
mstr2 has updated the pull request incrementally with one additional commit
since the last revision:
Fixed t
The children of HBox/VBox don't always pixel-snap to the same value as the
container itself when a render scale other than 1 is used. This can lead to a
visual glitch where the content bounds don't line up with the container bounds.
In this case, the container will extend beyond its content, or
This PR fixes incorrect parsing of mnemonic symbols in the following cases:
1. an escaped double underscore incorrectly shows up as a double underscore in
displayed text
2. an extended mnemonic incorrectly removes a part of adjacent text
As a side effect, this PR also fixes another undocumented
On Mon, 5 Apr 2021 21:54:40 GMT, Kevin Rushforth wrote:
>> The internal BidirectionalBinding class implements bidirectional bindings
>> for JavaFX properties. The design intent of this class is to provide
>> specializations for primitive value types to prevent boxing conversions (cf.
>>
The internal BidirectionalBinding class implements bidirectional bindings for
JavaFX properties. The design intent of this class is to provide
specializations for primitive value types to prevent boxing conversions (cf.
specializations of the Property class with a similar design intent).
On Tue, 6 Apr 2021 14:29:28 GMT, Nir Lisker wrote:
> The benchmark might not tell the real story. To test these sorts of
> performance changes you have to use JMH. There's too much relating to JIT
> optimizations and JVM startup to be able to rely on the current benchmark.
> The theoretical
> The Slider control does not have the ":horizontal" CSS pseudo-class set by
> default. The pseudo-class is only set once the "orientation" property is
> changed. This PR fixes that.
mstr2 has updated the pull request incrementally with one additional commit
sinc
The Slider control does not have the ":horizontal" CSS pseudo-class set by
default. The pseudo-class is only set once the "orientation" property is
changed. This PR fixes that.
-
Commit messages:
- 8089913: CSS styling problem with Slider pseudo classes
- Failing test
Changes:
On Fri, 26 Feb 2021 15:17:23 GMT, mstr2
wrote:
> The Slider control does not have the ":horizontal" CSS pseudo-class set by
> default. The pseudo-class is only set once the "orientation" property is
> changed. This PR fixes that.
This pull request has no
> The Slider control does not have the ":horizontal" CSS pseudo-class set by
> default. The pseudo-class is only set once the "orientation" property is
> changed. This PR fixes that.
mstr2 has updated the pull request incrementally with three additional commits
sin
> The Slider control does not have the ":horizontal" CSS pseudo-class set by
> default. The pseudo-class is only set once the "orientation" property is
> changed. This PR fixes that.
mstr2 has updated the pull request incrementally with two additional commits
since
ully:
>
> TableView
> TreeTableView
> TreeCell
> TreeTableRow
>
>
> @mstr2 I think the scope of this bug should be expanded to fix at least the
> `ListView` issue, since it is effectively the same bug as this, with the same
> pattern used for the fix and test. The Tree/Ta
> The Slider control does not have the ":horizontal" CSS pseudo-class set by
> default. The pseudo-class is only set once the "orientation" property is
> changed. This PR fixes that.
mstr2 has updated the pull request incrementally with one additional commit
since
On Fri, 5 Mar 2021 13:31:38 GMT, Kevin Rushforth wrote:
>> Thanks for the additional fixes. I'll change the title of the JBS bug to
>> "CSS pseudo classes missing by default for some controls". Can you change
>> the PR title to match?
>>
>> The changes to `ListView` and `TableView` look
On Fri, 5 Mar 2021 14:38:06 GMT, Kevin Rushforth wrote:
>> I guess that depends on whether a `TreeCell` or `TreeTableRow` that is not
>> expanded should be considered collapsed.
>>
>> Unless there are compelling reasons to have cells that are neither expanded
>> nor collapsed, I think it is
Fixes a bug in `ControlUtils.buildClearAndSelectChange` that reports a wrong
start index for the second range of a disjoint removed list.
-
Commit messages:
- ListChangeListener getRemoved() returns items that were not removed.
- Add failing test
Changes:
the correct index.
>
> `SelectedItemsReadOnlyObservableList` doesn't apply removals to
> `itemsRefList`, which means that subsequent removals will refer to the wrong
> index when retrieving the removed elements. This PR fixes the calculation of
> the current index.
mstr2 has refreshe
36 matches
Mail list logo
