On Tue, 14 Apr 2020 10:31:18 GMT, Jose Pereda wrote:
> There are cases when iOS sends one or more NSTouchPhaseMoved for a given
> touch event, in between NSTouchPhaseBegan and
> NSTouchPhaseEnded , even if the initial event location didn't change.
> By default, all these events are emulated as
On Thu, 5 Dec 2019 00:14:34 GMT, John Neffenger
wrote:
>> This pull request adds support for e-paper displays with the i.MX 6 Series
>> of Applications Processors and implements
>> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the
>> obsolete *javafxports/openjdk-jfx*
> This pull request adds support for e-paper displays with the i.MX 6 Series of
> Applications Processors and implements
> [Issue #521](https://github.com/javafxports/openjdk-jfx/issues/521) in the
> obsolete *javafxports/openjdk-jfx*
> repository. Some of the changes were made to support the
On Fri, 10 Apr 2020 06:31:39 GMT, Nir Lisker wrote:
> ### Cause
>
> `Animation#jumpTo(Duration)` does not handle `Duration.INDEFINITE` properly.
> This causes
> `InfiniteClipEnvelope#jumpTo(long)` to receive an erroneous value and start
> the animation not from the end, depending
> on the
On Thu, 16 Apr 2020 09:45:20 GMT, dannygonzalez
wrote:
>> @dannygonzalez Could you perhaps debug your application and take a look at
>> how large the following array is: a random
>> node -> `scene` -> `value` -> `window` -> `readOnlyProperty` -> `helper` ->
>> `changeListeners`. I just
On Thu, 16 Apr 2020 15:04:53 GMT, Jeanette Winzenburg
wrote:
>> Macroscopic issue is that initially, the toggle is not sync'ed to the
>> selection state. Root reason is an missing else
>> block when updating toggle selection state (see report for details).
>> Fixed by introducing the else
> Macroscopic issue is that initially, the toggle is not sync'ed to the
> selection state. Root reason is an missing else
> block when updating toggle selection state (see report for details).
> Fixed by introducing the else block and removing all follow-up errors that
> tried to amend the
On Thu, 16 Apr 2020 11:23:24 GMT, Ambarish Rapte wrote:
>>> 1. do nothing for a (don't feel like filing yet another bug around
>>> selection ;) and b (the skin behaves correctly, I
>>> think)
>>
>> I am good with this. Though I will file a JBS for the correction in
>>
On Thu, 9 Apr 2020 09:58:27 GMT, Jesper Skov
wrote:
> Make the two ways of associating a ToggleButton with a ToggleGroup interact
> correctly.
>
> This fixes https://bugs.openjdk.java.net/browse/JDK-8198402
/signed
-
PR: https://git.openjdk.java.net/jfx/pull/167
Make the two ways of associating a ToggleButton with a ToggleGroup interact
correctly.
This fixes https://bugs.openjdk.java.net/browse/JDK-8198402
-
Commit messages:
- 8198402: Fix ToggleButton leak in ToggleGroup
Changes: https://git.openjdk.java.net/jfx/pull/167/files
Webrev:
On Wed, 15 Apr 2020 23:18:46 GMT, Kevin Rushforth wrote:
>> Issue : https://bugs.openjdk.java.net/browse/JDK-8193286
>>
>> Root Cause :
>> Incorrect implementation.
>> Current implementation of int wrapValue(int,int,int) in Spinner.java works
>> well if min is 0.
>> Hence this implementation
On Thu, 16 Apr 2020 11:18:55 GMT, Ambarish Rapte wrote:
>> btw: just noticed that there are methods in ChoiceBoxSkin testing the fix
>> for next/prev
>>
>> @Test public void test_jdk_8988261_selectNext() {
>> @Test public void test_jdk_8988261_selectPrevious() {
>>
>> the name look
On Thu, 16 Apr 2020 09:17:19 GMT, Jeanette Winzenburg
wrote:
>> yeah, you are right:
>>
>> a) the implementation of ChoiceBoxSelectionModel is broken when it comes to
>> handling of unselectable items (such as
>> Separator): next/previous try to move on, the others simply select. The
>>
On Thu, 16 Apr 2020 08:46:26 GMT, John Hendrikx wrote:
>> If it is of any help, I have attached a VisualVM snapshot (v1.4.4) where the
>> ExpressionHelper.removeListener is using
>> 61% of the JavaFX thread whilst running our application.
>>
On Thu, 16 Apr 2020 09:05:12 GMT, Jeanette Winzenburg
wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/skin/ChoiceBoxSkin.java
>> line 416:
>>
>>> 415: } else {
>>> 416: toggleGroup.selectToggle(null);
>>> 417: }
>>
>>
On Wed, 15 Apr 2020 15:52:13 GMT, Ambarish Rapte wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> ChoiceBox: added FIXME with reference to issue
>
>
On Wed, 15 Apr 2020 15:46:16 GMT, Ambarish Rapte wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> ChoiceBox: added FIXME with reference to issue
>
>
On Thu, 16 Apr 2020 08:24:16 GMT, dannygonzalez
wrote:
>> The listeners added by `Node` are apparently internally required for
>> internal properties `TreeShowing` and
>> `TreeVisible`, and are used to take various decisions like whether to
>> play/pause animations. There is also a couple of
On Wed, 15 Apr 2020 23:17:56 GMT, Alexander Matveev
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8242530
>
> - GstElementClass which is base class for all elements has same instance
> between all spectrum elements (not sure if it is
> same for all elements) and thus post_message was
On Thu, 16 Apr 2020 07:34:40 GMT, John Hendrikx wrote:
>> Looking at the commit
>> https://github.com/openjdk/jfx/commit/e21606d3a1b73cd4b44383babc750a4b4721edfd
>> it seems that the long listener lists are actually part of the `Scene`'s
>> `Window` property and the `Window`'s `Showing`
>>
On Thu, 16 Apr 2020 07:11:58 GMT, John Hendrikx wrote:
>> The patch proposed here does not share the case where the listener deletion
>> performance becomes a bottleneck.
>>
>> I think that it is necessary to reproduce it by testing first, but
>>
>> If you just focus on improving listener
On Thu, 16 Apr 2020 06:34:39 GMT, yosbits
wrote:
>> @hjohn
>> I haven't quantified exactly where all the listeners are coming from but the
>> Node class for example has various
>> listeners on it.
>> The following changeset (which added an extra listener on the Node class)
>> impacted
On Wed, 15 Apr 2020 07:11:27 GMT, dannygonzalez
wrote:
>> @dannygonzalez You mentioned "There are multiple change listeners on a Node
>> for example, so you can imagine with the
>> number of nodes in a TableView this is going to be a problem if the
>> unregistering is slow.".
>> Your changes
23 matches
Mail list logo
