On Wed, 9 Feb 2022 18:27:55 GMT, Ajit Ghaisas wrote:
>> This is a Javadoc cleanup and correction fix for the TabPane as described in
>> the JBS.
>>
>> Changes done for all the Properties of the TabPane -
>> - Moved the property description to be over the property field.
>> - Removed the
Hi,
When reviewing the docs changes to TabPane, I saw that some properties
mention the CSS that is related to them. I was wondering if we could
standardize it through something like a @css tag that is given the css
string constant, or read automatically through the CssMetaData.
As an example:
On Wed, 9 Feb 2022 13:17:14 GMT, Kevin Rushforth wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
>> 738:
>>
>>> 736:
>>> 737: /**
>>> 738: * This specifies how the {@code TabPane} handles tab closing
>>> from an end-user's
>>
>> Since you are
On Wed, 9 Feb 2022 07:32:20 GMT, Ajit Ghaisas wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
>> 295:
>>
>>> 293: *
>>> 294: * This value can also be set via CSS using {@code
>>> -fx-tab-min-width}.
>>> 295: *
>>
>> I would write
>>
>>
On Wed, 9 Feb 2022 09:39:46 GMT, Ajit Ghaisas wrote:
>> This is a Javadoc cleanup and correction fix for the TabPane as described in
>> the JBS.
>>
>> Changes done for all the Properties of the TabPane -
>> - Moved the property description to be over the property field.
>> - Removed the
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote:
> This is a Javadoc cleanup and correction fix for the TabPane as described in
> the JBS.
>
> Changes done for all the Properties of the TabPane -
> - Moved the property description to be over the property field.
> - Removed the unnecessary
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote:
> This is a Javadoc cleanup and correction fix for the TabPane as described in
> the JBS.
>
> Changes done for all the Properties of the TabPane -
> - Moved the property description to be over the property field.
> - Removed the unnecessary
On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote:
> Now that the standard concrete light types were added, there is an
> opportunity to rearrange and rewrite some of the class docs. Here is a
> summary of the changes:
>
> * Moved the explanations of attenuation a
On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote:
>> Now that the standard concrete light types were added, there is an
>> opportunity to rearrange and rewrite some of the class docs. Here is a
>> summary of the changes:
>>
>> * Moved the explanations o
On Thu, 27 Jan 2022 19:01:32 GMT, Kevin Rushforth wrote:
>> I think the description should focus on the meaning of the respective term
>> in the lighting equation, and not on a non-technical analogy. In this case,
>> the analogy is a bit misleading on several aspects, including the fact that
it
> mentioned the properties it has.
> * Added examples of real-world applications for each light type.
> * Consolidated the writing style for all the subclasses.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
it
> mentioned the properties it has.
> * Added examples of real-world applications for each light type.
> * Consolidated the writing style for all the subclasses.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Fixed tabl
it
> mentioned the properties it has.
> * Added examples of real-world applications for each light type.
> * Consolidated the writing style for all the subclasses.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Added implNote
it
> mentioned the properties it has.
> * Added examples of real-world applications for each light type.
> * Consolidated the writing style for all the subclasses.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Addressed
On Tue, 25 Jan 2022 01:17:51 GMT, Kevin Rushforth wrote:
>> Now that the standard concrete light types were added, there is an
>> opportunity to rearrange and rewrite some of the class docs. Here is a
>> summary of the changes:
>>
>> * Moved the explanations of attenuation and direction up to
On Tue, 25 Jan 2022 06:21:37 GMT, Ambarish Rapte wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/AmbientLight.java line 37:
>>
>>> 35: *
>>> 36: * {@code AmbientLight}s can represent strong light sources in an
>>> enclosed area where the lights bounces from many
>>> 37: *
Got it, thanks.
On Fri, Jan 21, 2022 at 11:08 AM Florian Kirmaier <
florian.kirma...@gmail.com> wrote:
> Hi Nir Lisker,
>
> Yes, these are required.
> Btw, here is the link to the project, which can be used independently of
> OpenJFX: https://github.com/Sandec/JMemory
Hi,
Looking at JMemoryBuddy, there are unused fields and methods. It's not
clear if they were left in by mistake or are part of future work.
* line 89: AssertCollectable assertCollectable = new
AssertCollectable(weakReference);
* line 237: the method setMxBeanProxyName
* line 309:
On Mon, 10 Jan 2022 21:09:15 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
>
> 1. If your main class extends Application, and you try to run it like:
> java -jar MyApplication.jar
> It will fail immediately with:
> Error: JavaFX runtime components are missing, and are required to run this
> application
> 2. If you "trick" it, by making your Application class a
Now that the standard concrete light types were added, there is an opportunity
to rearrange and rewrite some of the class docs. Here is a summary of the
changes:
* Moved the explanations of attenuation and direction up to `LightBase` since
different light types share characteristics.
On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote:
> Now that the standard concrete light types were added, there is an
> opportunity to rearrange and rewrite some of the class docs. Here is a
> summary of the changes:
>
> * Moved the explanations of attenuation a
On Mon, 10 Jan 2022 21:09:15 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
Hi,
Many @FunctionalInterface interfaces declare explicitly what their
functional method is, For example, the java.util.function interfaces. I was
wondering if the docs pointing out which is the functional method
automatically would be of any use.
If so, the question becomes what is the best
On Wed, 5 Jan 2022 12:29:01 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
On Wed, 5 Jan 2022 10:51:28 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/javafx/beans/value/ObservableValue.java
>> line 152:
>>
>>> 150: * @return an {@link ObservableValue} which provides a mapping of
>>> the value
>>> 151: * held by this {@code
On Wed, 5 Jan 2022 12:29:01 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
On Mon, 28 Jun 2021 12:13:44 GMT, Nir Lisker wrote:
> Adds a directional light as a subclass of `LightBase`. I think that this is
> the correct hierarchy for it.
>
> I tried to simulate a directional light by putting a point light far away,
> but I got artifacts when the dis
On Mon, 20 Dec 2021 13:13:09 GMT, Nir Lisker wrote:
>> Adds a directional light as a subclass of `LightBase`. I think that this is
>> the correct hierarchy for it.
>>
>> I tried to simulate a directional light by putting a point light far away,
>> but I g
On Wed, 5 Jan 2022 09:52:29 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/javafx/beans/binding/ObjectBinding.java
>> line 204:
>>
>>> 202: *
>>> 203: * @return {@code true} if this binding is allowed to become
>>> valid, otherwise
>>> 204: * {@code false}
On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
On Wed, 15 Dec 2021 11:43:36 GMT, John Hendrikx wrote:
>> This is an implementation of the proposal in
>> https://bugs.openjdk.java.net/browse/JDK-8274771 that me and Nir Lisker
>> (@nlisker) have been working on. It's a complete implementation including
>
.
>
> I added a system test that verifies the correct color result from a few
> directions. I also updated the lighting sample application to include 3
> directional lights and tested them on all the models visually. The lights
> seem to behave the way I would expect.
Nir Lisker has u
On Mon, 20 Dec 2021 12:57:51 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes for review comments
>
> tests/performance/3DLighting/attenuation/Environment.
On Sat, 18 Dec 2021 16:34:21 GMT, Kevin Rushforth wrote:
>> Btw, you don't need the "abs" for the gLightAttenuation check (you don't
>> have it now when checking against 0.5) so you can just change it to
>> `gLightAttenuation[i].w < EPSILON` which seems cleaner than testing against
>> 0.5.
>
.
>
> I added a system test that verifies the correct color result from a few
> directions. I also updated the lighting sample application to include 3
> directional lights and tested them on all the models visually. The lights
> seem to behave the way I would expect.
Nir Lisker has u
On Tue, 7 Dec 2021 16:38:03 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year
>
> modules/javafx.graphics/src/main/native-prism-d3d/hlsl/psMath.
.
>
> I added a system test that verifies the correct color result from a few
> directions. I also updated the lighting sample application to include 3
> directional lights and tested them on all the models visually. The lights
> seem to behave the way I would expect.
Nir Lisker has u
.
>
> I added a system test that verifies the correct color result from a few
> directions. I also updated the lighting sample application to include 3
> directional lights and tested them on all the models visually. The lights
> seem to behave the way I would expect.
Nir Lisker has u
On Tue, 7 Dec 2021 16:22:25 GMT, Kevin Rushforth wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update copyright year
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/sce
On Fri, 17 Dec 2021 15:18:51 GMT, Kevin Rushforth wrote:
>> This PR updates the `CONTRIBUTING.md` guide to address the following:
>>
>> 1. Clarify the process for adding new features / API changes, specifically
>> that they must be discussed on the mailing list as the first step.
>> 2. Add a
On Fri, 17 Dec 2021 14:08:23 GMT, Michael Strauß wrote:
>> Kevin Rushforth has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Minor updates
>
> CONTRIBUTING.md line 18:
>
>> 16:
>> 17:
>> 18: If you find yourself wishing
On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote:
>> This PR updates the `CONTRIBUTING.md` guide to address the following:
>>
>> 1. Clarify the process for adding new features / API changes, specifically
>> that they must be discussed on the mailing list as the first step.
>> 2. Add a
On Fri, 17 Dec 2021 13:33:57 GMT, Kevin Rushforth wrote:
>> This PR updates the `CONTRIBUTING.md` guide to address the following:
>>
>> 1. Clarify the process for adding new features / API changes, specifically
>> that they must be discussed on the mailing list as the first step.
>> 2. Add a
On Wed, 17 Nov 2021 05:34:46 GMT, Abhinay Agarwal wrote:
> This work improves the performance of `MultipleSelectionModel` over large
> data sets by caching some values and avoiding unnecessary calls to
> `SelectedIndicesList#size`. It further improves the performance by reducing
> the number
On Tue, 21 Sep 2021 11:13:06 GMT, Nir Lisker wrote:
> Replacements of more immutable collections.
>
> One thing I found was that the field `idMap` in
> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
> if that's indeed the case.
This pull reque
On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker wrote:
>> Replacements of more immutable collections.
>>
>> One thing I found was that the field `idMap` in
>> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
>> if that's indeed the ca
> Replacements of more immutable collections.
>
> One thing I found was that the field `idMap` in
> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
> if that's indeed the case.
Nir Lisker has updated the pull request incrementally with one additiona
On Fri, 29 Oct 2021 11:42:38 GMT, Ajit Ghaisas wrote:
>> This PR deprecates mistakenly exposed field from class
>> javafx.scene.shape.Box.
>
> Ajit Ghaisas has updated the pull request incrementally with one additional
> commit since the last revision:
>
> review fix
Marked as reviewed by
On Thu, 28 Oct 2021 14:27:52 GMT, Ajit Ghaisas wrote:
>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under -
>>
On Thu, 28 Oct 2021 07:23:53 GMT, Ajit Ghaisas wrote:
>> This PR fixes javadoc warnings primarily in javafx.graphics module along
>> with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>>
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> -
On Tue, 26 Oct 2021 06:24:35 GMT, Ajit Ghaisas wrote:
>> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> - 2 javadoc warnings in javafx.controls TabPane class will be fixed under -
>>
On Tue, 26 Oct 2021 09:54:43 GMT, Ajit Ghaisas wrote:
>> This PR fixes javadoc warnings primarily in javafx.graphics module along
>> with a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>>
>> Note :
>> - The javadoc needs to be generated with the JDK 18 EA build.
>> -
On Wed, 27 Oct 2021 15:58:38 GMT, Nir Lisker wrote:
>> Ajit Ghaisas has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> fix review comments
>
> modules/javafx.graphics/src/main/java/javafx/stage/W
On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker wrote:
>> Replacements of more immutable collections.
>>
>> One thing I found was that the field `idMap` in
>> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
>> if that's indeed the ca
On Sun, 24 Oct 2021 16:04:40 GMT, Andreas Heger wrote:
> I tried to use the Node.snapshot method, but in this case the taken snapshot
> always had the correct illumination, no matter what display was used and even
> though the scene on the display showed the wrong illumination. I guess the
>
On Fri, 22 Oct 2021 17:53:27 GMT, Kevin Rushforth wrote:
> The PR fixes the broken links as described in the JBS issue. The correct link
> for the Oracle Contributor Agreement (OCA) is:
>
> https://oca.opensource.oracle.com/
Marked as reviewed by nlisker (Reviewer).
-
PR:
On Fri, 22 Oct 2021 11:23:07 GMT, Ajit Ghaisas wrote:
> This PR fixes javadoc warnings primarily in javafx.graphics module along with
> a remaining few in javafx.fxml, javafx.base and javafx.media modules.
>
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are
On Wed, 20 Oct 2021 14:42:44 GMT, Ajit Ghaisas wrote:
> This PR fixes javadoc warnings in javafx.controls and javafx.web modules.
> Note :
> - The javadoc needs to be generated with the JDK 18 EA build.
> - There are still 20 javadoc warnings remaining in javafx.controls module and
> 3
dy fixed
> > -- this specific fix might have been the one that introduced the #get
> > call in ExpressionHelper.
> >
> > On 06/10/2021 04:38, Nir Lisker wrote:
> >> I would also answer "no" to both points. This is also what the docs say.
> >>
> &
On Fri, 15 Oct 2021 14:24:15 GMT, Nir Lisker wrote:
>> Replacements of more immutable collections.
>>
>> One thing I found was that the field `idMap` in
>> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
>> if that's indeed the ca
> Replacements of more immutable collections.
>
> One thing I found was that the field `idMap` in
> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
> if that's indeed the case.
Nir Lisker has updated the pull request incrementally with one additiona
On Thu, 14 Oct 2021 23:50:10 GMT, Kevin Rushforth wrote:
>> Replacements of more immutable collections.
>>
>> One thing I found was that the field `idMap` in
>> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
>> if that's indeed the case.
>
>
ink it's something we can and should consider changing. Unless there
> > are serious concerns, I would support changing this behavior as part of
> > avoiding eager evaluation when using invalidation listeners. It would
> > need to be well tested (of course), and would need a CS
On Tue, 24 Aug 2021 16:29:11 GMT, Nir Lisker wrote:
> Added convenience factory factory methods for Background and Border.
This pull request has now been integrated.
Changeset: bb73d43b
Author: Nir Lisker
URL:
https://git.openjdk.java.net/jfx/com
ity risk, and should probably get a release note.
>
> Any concerns in doing this?
>
> On the related question, I like the idea of nulling out the current value
> when a property is bound.
>
> -- Kevin
>
>
> On 9/11/2021 9:41 AM, Nir Lisker wrote:
>
> I think that we
I've created https://bugs.openjdk.java.net/browse/JDK-8274771
>
> Please have a look.
>
> --John
>
> On 04/10/2021 17:51, Nir Lisker wrote:
> > I think that a PR can be created. The only point we need to decide is
> about
> > the subscription models we talked abo
and a draft CSR if you want.
On Tue, Sep 21, 2021 at 1:36 PM Nir Lisker wrote:
> The OrElseBinding is incorrect
>>
>
> Yes, that was a typo with the order of the arguments in the ternary
> statement.
>
> I can rewrite the tests for JUnit 4 but I'd need a Nested runner (I
be added later if there is a compelling need.
>
> -- Kevin
>
> On 9/24/2021 4:50 AM, Nir Lisker wrote:
>
> I don't have a strong opinion on this addition.
>
> On Fri, Sep 24, 2021 at 2:47 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I do
I much prefer JUnit 5 to 4, so I'm in favor.
On Sat, Sep 25, 2021 at 12:40 AM John Hendrikx wrote:
> Posting this to gauge the interest in adding JUnit 5 as a test
> dependency to JavaFX, enabling writing tests with this new version of
> JUnit while still supporting all JUnit 4 tests.
>
> A
s a
> > convenience method.
> > Any other use case is likely to be so complex that it makes sense to
> > use the normal existing constructors.
> >
> > Feel free to share you opinion.
> >
> > - Marius
> >
> > Gesendet:
On Thu, 23 Sep 2021 18:03:37 GMT, Marius Hanl wrote:
>> Replacements of more immutable collections.
>>
>> One thing I found was that the field `idMap` in
>> `com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it
>> if that's indeed the case.
>
>
On Thu, 23 Sep 2021 21:55:57 GMT, delvh
wrote:
>> We still build JavaFX with `--release 11` so applications using JavaFX can
>> run on JDK 11 or later. At some point we will bump the minimum version of
>> Java that is required, but until then we cannot use records or any other
>> feature
Replacements of more immutable collections.
One thing I found was that the field `idMap` in
`com.sun.java.scene.web.WebViewHelper.WebView` seems unused. I can remove it if
that's indeed the case.
-
Commit messages:
- Fix a previous change
- More leftovers
- Unified style
- Fix
On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote:
> As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and
> `ES2Graphics` are now identical, which should have been the case all along.
> The fact that they weren't identical was the source of a bug that was only
> discovered
t;
> > On September 21, 2021 at 5:36:13 AM CDT, Nir Lisker (mailto:nlis...@gmail.com)> wrote:
> > >
> > > The OrElseBinding is incorrect
> > >
> >
> > Yes, that was a typo with the order of the arguments in the ternary
> > statement.
> >
>
On Tue, 21 Sep 2021 12:45:20 GMT, Kevin Rushforth wrote:
> As mentioned in JBS, the `clearQuad` methods in `D3DGraphics` and
> `ES2Graphics` are now identical, which should have been the case all along.
> The fact that they weren't identical was the source of a bug that was only
> discovered
ed one available)
> - Create our own nested runner (about 200 lines of code)
> - Can we introduce JUnit 5?
> - Rewrite to plain JUnit 4?
>
> Let me know, and I can integrate them.
>
> --John
>
> On 19/09/2021 02:12, Nir Lisker wrote:
> > I've played around with
On Sun, 19 Sep 2021 10:53:02 GMT, Marius Hanl wrote:
>>> > ```
>>> > public static Border stroke(Paint stroke, double width) {
>>> > ```
>>> > ...
>>> > But I really want to hear other opinions. This can also be a follow up. :)
>>>
>>> I don't mind adding this variant, but it needs consensus.
> Added convenience factory factory methods for Background and Border.
Nir Lisker has updated the pull request incrementally with one additional
commit since the last revision:
Added null tests and changed doc as per comments
-
Changes:
- all: https://git.openjdk.java.net/
On Wed, 15 Sep 2021 11:16:39 GMT, Ambarish Rapte wrote:
> Above one will just be uniform with existing doc.
In this case it doesn't matter much, but in general I don't like many places of
the `Background` and `Border` docs as they stand :)
I already looked at them as a starting point when
name clash if the Optional
ones will have support.
[1]
https://github.com/openjdk/jfx-sandbox/tree/jfx-sandbox/nlisker_fuent_bindings
On Wed, Sep 15, 2021 at 1:59 PM John Hendrikx wrote:
>
>
> On 15/09/2021 02:28, Nir Lisker wrote:
> > Sorry, I'm not quite sure what you mean by
On Thu, 16 Sep 2021 21:15:20 GMT, Kevin Rushforth wrote:
> I agree that it needs consensus, so the question is how many apps would use
> it from code (as opposed to CSS), and be satisfied with the other defaults. I
> don't object to adding a 2nd variant that takes a stroke width as long as we
On Thu, 16 Sep 2021 08:36:49 GMT, Marius Hanl wrote:
> One comment from my side: I would find it quite useful if we have another
> border factory method with a double as the second parameter which let us
> specify the border width. So e.g.
>
> ```
> public static Border stroke(Paint stroke,
On Wed, 15 Sep 2021 11:08:04 GMT, Ambarish Rapte wrote:
>> Nir Lisker has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Removed whitespaces
>> - Added tests and doc updates
>
> modules/javafx.grap
for
now, especially when Valhalla is planned to take care of those.
The ticket is a bit unclear as I can't see what type "x" is.
>
Yes, but I got the impression that either way it can be solved with map (or
flatMap).
On Tue, Sep 14, 2021 at 8:44 AM John Hendrikx wrote:
>
>
>
://bugs.openjdk.java.net/browse/JDK-8091544
https://bugs.openjdk.java.net/browse/JDK-8091316
On Mon, Sep 13, 2021 at 3:05 AM John Hendrikx wrote:
>
>
> On 12/09/2021 02:05, Nir Lisker wrote:
> > I've gotten back to look at this.
> >
> > For now I'm dealing only with the nullableMapping metho
Vote: YES
On Mon, Sep 13, 2021 at 5:45 PM Pankaj Bansal
wrote:
> Vote: YES
>
> From: openjfx-dev on behalf of Kevin
> Rushforth
> Date: Monday, 13 September 2021 at 8:07 PM
> To: openjfx-dev@openjdk.java.net , Thiago
> Milczarek Sayao
> Subject: CFV: New OpenJFX Committer: Thiago Sayao
> I
to replace the Bindings.select (non-type safe) API, can we do
it with our current way of treating null?
Do you think that this is a valid approach?
- Nir
On Wed, Apr 7, 2021 at 11:30 PM John Hendrikx wrote:
> On 07/04/2021 03:41, Nir Lisker wrote:
> > In the PoC I made I specific
I think that we need your input on this to move it forward.
On Fri, Sep 3, 2021 at 7:49 AM Nir Lisker wrote:
> so the value field should perhaps be nulled out when bound.
>
>
> There was a PR for something like that in the old repo:
> https://github.com/javafxports/openj
On Thu, 9 Sep 2021 23:43:29 GMT, Nir Lisker wrote:
>> Added convenience factory factory methods for Background and Border.
>
> Nir Lisker has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Removed whitespaces
>
> Added convenience factory factory methods for Background and Border.
Nir Lisker has updated the pull request incrementally with two additional
commits since the last revision:
- Removed whitespaces
- Added tests and doc updates
-
Changes:
- all: https://git.openjdk.java.
On Tue, 7 Sep 2021 06:31:18 GMT, Ambarish Rapte wrote:
>> Since the `Background` constructors take a list of `Paint` objects, I think
>> saying a "single" `{@code Paint}` is helpful. I can see how adding "for
>> `BackgroundFill`" (or maybe "as a `BackgroundFill`"?) might make it clearer.
>
>
On Fri, 3 Sep 2021 21:08:27 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Background.java
>> line 366:
>>
>>> 364: */
>>> 365: public static Background fill(Paint fill) {
>>> 366: return new Background(new BackgroundFill(fill, null,
? Not sure if this is inconvenient only for me.
On Sat, Aug 28, 2021 at 2:56 AM Nir Lisker wrote:
> The problem I have with additional booleans is that they are not
> reflected in the transitions, and to a lesser extent in the transforms.
>
> I'm going to have to write an implementat
On Tue, 7 Sep 2021 08:37:31 GMT, Ambarish Rapte wrote:
>> Good idea to indicate what happens on `null`, although that might be better
>> in the description?
>
> I think that should be fine too.
> How should we describe the @param in that case.
> `@param fill Any Paint as BackgroundFill` ->
On Sun, 29 Aug 2021 04:12:22 GMT, Michael Strauß wrote:
> This PR fixes a bug that was introduced in #454.
>
> Since this fix might impact the performance considerations in the original
> PR, I ran a performance benchmark against the previous `ChangeListener`-based
> implementation, which
I would submit it to bugreport.java.com.
On Thu, Sep 2, 2021 at 9:08 PM Troels Skytte Kaspersen wrote:
> Hi,
>
> We have received many complaints from our customers that the popups are
> not shown anymore after a period of time.
>
> I have then created a simple piece of code that result in the
>
> so the value field should perhaps be nulled out when bound.
There was a PR for something like that in the old repo:
https://github.com/javafxports/openjdk-jfx/pull/110
On Fri, Sep 3, 2021 at 5:35 AM John Hendrikx wrote:
>
>
> On 02/09/2021 11:57, Nir Lisker wrote:
>
701 - 800 of 1528 matches
Mail list logo
