> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127:
Fixed some more testcases
-
Changes:
- all: https://git.openjdk.java.net/jfx/pu
On Wed, 14 Apr 2021 11:45:17 GMT, Florian Kirmaier
wrote:
>> Fixing ListCell editing status is true, when index changes while editing.
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8264127:
> Fixed some more testca
> Fixing ListCell editing status is true, when index changes while editing.
Florian Kirmaier has updated the pull request incrementally with one additional
commit since the last revision:
8264127:
Added checks, whether the correction ammount of editStart/cancel events are
triggered
---
On Wed, 14 Apr 2021 11:45:17 GMT, Florian Kirmaier
wrote:
>> Fixing ListCell editing status is true, when index changes while editing.
>
> Florian Kirmaier has updated the pull request incrementally with one
> additional commit since the last revision:
>
> 8264127:
> Fixed some more testca
On Mon, 12 Apr 2021 20:30:55 GMT, Kevin Rushforth wrote:
> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
> support, so we should update this minimum. Further, macOS / aarch64 (aka
> arm6
On Mon, 8 Mar 2021 17:32:20 GMT, John Neffenger wrote:
>> Long term, yes.
>>
>> I am currently low on time and my Java-foo is not that great, so I was
>> hoping that someone would pick it up.
>
>> I am currently low on time and my Java-foo is not that great, so I was
>> hoping that someone wou
> https://bugs.openjdk.java.net/browse/JDK-8185886
>
> Optimisation to ExpressionHelper.Generic class to use Sets rather than Arrays
> to improve listener removal speed.
>
> This was due to the removal of listeners in TableView taking up to 50% of CPU
> time on the JavaFX Application thread whe
On Wed, 15 Apr 2020 02:35:44 GMT, Bernhard M. Wiedemann
wrote:
> I am currently low on time and my Java-foo is not that great, so I was hoping
> that someone would pick it up.
@bmwiedemann Thank you for getting this important change started. If you can
finish this pull request, I'll follow up
On Tue, 9 Mar 2021 03:11:48 GMT, Bernhard M. Wiedemann
wrote:
> When linking shared libraries, ensure that .o files are listed in
> deterministic order - i.e. `sort(glob(*.c))` and check if individual .c or .o
> files vary between builds.
Wow, that tip was priceless! Thank you, Bernhard. It t
On Fri, 26 Mar 2021 19:19:10 GMT, John Neffenger wrote:
> objectDir.listFiles().sort()
Now the interesting question is, if it is possible to change `listFiles` to
always return deterministic output or if we have to patch an infinite number of
callers instead. For those cases where people do no
On Sat, 27 Mar 2021 03:34:11 GMT, Bernhard M. Wiedemann
wrote:
> Now the interesting question is, if it is possible to change `listFiles` to
> always return deterministic output ...
Yes, that would be interesting, if `listFiles()` were defined by the Gradle
build tool. I think it originates,
On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann
wrote:
> Allow to override buildDate with `SOURCE_DATE_EPOCH`
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the defin
On Sat, 27 Mar 2021 17:26:21 GMT, John Neffenger wrote:
> The API states, "There is no guarantee that the name strings in the resulting
> array will appear in any specific order; they are not, in particular,
> guaranteed to appear in alphabetical order." That API was defined in December
> 1998
On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann
wrote:
> Allow to override buildDate with `SOURCE_DATE_EPOCH`
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the defin
On Sat, 27 Mar 2021 18:49:32 GMT, Bernhard M. Wiedemann
wrote:
> Sorted output still complies with that API, though.
Well, that's true. I hadn't thought of it that way.
I have tried twice and failed to [add you as a
contributor](https://github.com/openjdk/jfx/pull/422#issuecomment-806317783)
> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
> support, so we should update this minimum. Further, macOS / aarch64 (aka
> arm64) requires macOS 11.0 as a minimum in order to run.
>
> T
On Wed, 14 Apr 2021 12:18:00 GMT, Ambarish Rapte wrote:
>> Kevin Rushforth has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update to use isAarch64 per review comments
>
> buildSrc/mac.gradle line 59:
>
>> 57: // Note that this is not ne
On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote:
>> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
>> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
>> support, so we should update this minimum. Further, macOS / aarch64 (aka
>>
On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote:
>> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
>> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
>> support, so we should update this minimum. Further, macOS / aarch64 (aka
>>
On Tue, 13 Apr 2021 13:13:50 GMT, Kevin Rushforth wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove mt.exe from win.gradle build script
>
> buildSrc/win.gradle line 468:
>
>> 466: case "aarch6
On Tue, 13 Apr 2021 13:04:53 GMT, Kevin Rushforth wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove mt.exe from win.gradle build script
>
> buildSrc/win.gradle line 474:
>
>> 472: boolean isExecutable
On Wed, 14 Apr 2021 13:44:49 GMT, Alexander Scherbatiy
wrote:
>> buildSrc/win.gradle line 474:
>>
>>> 472: boolean isExecutable(String file) {
>>> 473: try {
>>> 474: Runtime.runtime.exec(file)
>>
>> Is there a way other than to execute the command in question -- `rc` or
>> `fxc`
On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy
wrote:
>> This is a proposal for cross compiling JavaFX base modules (excluding media
>> and webkit) for Windows AArch64 (ARM64).
>>
>> Main changes:
>> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition
>> - HOST_ARCH a
On Tue, 13 Apr 2021 08:41:12 GMT, Alexander Scherbatiy
wrote:
>> This is a proposal for cross compiling JavaFX base modules (excluding media
>> and webkit) for Windows AArch64 (ARM64).
>>
>> Main changes:
>> - prismES2 native compilation is moved under IS_INCLUDE_ES2 condition
>> - HOST_ARCH a
On Wed, 14 Apr 2021 14:38:05 GMT, Johan Vos wrote:
>> Alexander Scherbatiy has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Remove mt.exe from win.gradle build script
>
> buildSrc/win.gradle line 46:
>
>> 44: def HOST_ARCH = getWinArch(e
On Wed, 14 Apr 2021 14:56:16 GMT, Kevin Rushforth wrote:
>> buildSrc/win.gradle line 46:
>>
>>> 44: def HOST_ARCH = getWinArch(ext.OS_ARCH)
>>> 45: def TARGET_ARCH = getWinArch(ext.TARGET_ARCH)
>>> 46: def IS_CROSS = HOST_ARCH != TARGET_ARCH
>>
>> can we move this to build.gradle?
>> With the i
On Wed, 14 Apr 2021 12:40:29 GMT, Kevin Rushforth wrote:
>> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
>> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
>> support, so we should update this minimum. Further, macOS / aarch64 (aka
>>
On Mon, 12 Apr 2021 20:30:55 GMT, Kevin Rushforth wrote:
> As noted in the JBS bug, the minimum macOS version on which JavaFX will run
> is currently set to 10.10 in `mac.gradle`. macOS 10.10 is many years out of
> support, so we should update this minimum. Further, macOS / aarch64 (aka
> arm6
On Wed, 29 Jan 2020 08:58:47 GMT, Bernhard M. Wiedemann
wrote:
> Allow to override buildDate with `SOURCE_DATE_EPOCH`
> in order to make builds reproducible.
> See https://reproducible-builds.org/ for why this is good
> and https://reproducible-builds.org/specs/source-date-epoch/
> for the defin
On Sun, 4 Apr 2021 16:36:27 GMT, John Neffenger wrote:
>> This pull request allows for reproducible builds of JavaFX on Linux, macOS,
>> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For
>> example, the following commands create a reproducible build:
>>
>>
>> $ export
> Added a SpotLight only to the D3D pipeline currently.
>
> ### API discussion points
>
> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could also
> be a subclass of `PointLight` as it's a point light with direction and extra
> factors. I saw that `scenario.effect.light.Spo
On Thu, 15 Apr 2021 02:21:50 GMT, Nir Lisker wrote:
>> Added a SpotLight only to the D3D pipeline currently.
>>
>> ### API discussion points
>>
>> - [X] Added `SpotLight` as a subclass of `LightBase`. However, it could
>> also be a subclass of `PointLight` as it's a point light with direction
On Fri, 9 Apr 2021 21:10:46 GMT, Matthias Bläsing
wrote:
>> The functions from FileSystemJava are called from different threads the
>> root problem manifests because the JNI FindClass function behaves
>> differently when called from a context that is the ancestor of a java
>> frame compared to w
33 matches
Mail list logo
