Hi,
I would assume that all projects with many dependencies are upgrading
their JDK slowly. Because you obviously need all your dependencies to
support the new JDK. Which means that the JDK is necessarily the last
thing to update.
With our project we have hundreds of dependencies, some
`Node` adds InvalidationListeners to its parent's `disabled` and `treeVisible`
properties and calls its own `updateDisabled()` and
`updateTreeVisible(boolean)` methods when the property values change.
These listeners are not required, since `Node` can easily call the
`updateDisabled()` and
On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier wrote:
>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer
>> is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race
On Wed, 20 Jul 2022 19:33:43 GMT, Phil Race wrote:
>> Florian Kirmaier has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> JDK-8271395
>> QuantumRenderer is no longer public
>
>
Hi,
I'd like to propose an API change in Skin interface (details below). Your
feedback will be greatly appreciated!
Thank you,
-andy
Summary
---
Introduce a new Skin.install() method with an empty default implementation.
Modify Control.setSkin(Skin) implementation to invoke
On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier wrote:
>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer
>> is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race
On Wed, 8 Sep 2021 07:52:31 GMT, Florian Kirmaier wrote:
>> This PR switches the Thread to the QuantumRenderer, in the case the Disposer
>> is called from another Thread - the printing Thread.
>> I'm open for better solutions on how to fix this Issue.
>> Initially i thought there is also a Race
Hi,
Am Mittwoch, dem 20.07.2022 um 15:40 +0300 schrieb Nir Lisker:
> The idea that an LTS JDK version is a good jumping point relies on
> the assumption that users upgrade their JDK slowly (once every 2-3
> years), but their JavaFX fast (once every 6 months). That is, they
> want LTS for their
On Sun, 17 Jul 2022 18:59:22 GMT, Johan Vos wrote:
>> Do not recalculate total estimated size recursively.
>>
>> In the (unlikely) event that the recalculation triggers a new recalculation
>> (e.g. when the height of a Cell is changed), do not start this recalculation.
>> The cache and cache
On Tue, 19 Jul 2022 10:36:07 GMT, Johan Vos wrote:
>> Do not recalculate total estimated size recursively.
>>
>> In the (unlikely) event that the recalculation triggers a new recalculation
>> (e.g. when the height of a Cell is changed), do not start this recalculation.
>> The cache and cache
In my opinion, each JDK version should be evaluated according to its
benefits to JavaFX and not according to LTS, which is a foreign concept to
OpenJDK.
The JDK moved to a 6 months release plan so it can innovate faster without
waiting several years to release an important feature, and if we go
On Tue, 19 Jul 2022 10:36:07 GMT, Johan Vos wrote:
>> Do not recalculate total estimated size recursively.
>>
>> In the (unlikely) event that the recalculation triggers a new recalculation
>> (e.g. when the height of a Cell is changed), do not start this recalculation.
>> The cache and cache
Dealing with the second question (when do we bump the version post-JFX20),
On Tue, Jul 19, 2022 at 10:39 PM Philip Race wrote:
...
> What to do in future (ie what is the policy) is a separate question
>
> OpenJDK LTS releases will be every two years in future, so there is a
> reasonable
13 matches
Mail list logo
