On Tue, 3 Jan 2023 23:56:12 GMT, Nir Lisker wrote:
>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
>> expand/collapse events. The graphics node needs to be released from the
>> previous checkbox so that it doesn't serve as the graphics of more tha
On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker wrote:
> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
> expand/collapse events. The graphics node needs to be released from the
> previous checkbox so that it doesn't serve as the graphics of more than one
&
On Sun, 1 Jan 2023 16:08:15 GMT, John Hendrikx wrote:
>> Packages fixed:
>> - com.sun.javafx.binding
>> - com.sun.javafx.collections
>> - javafx.beans
>> - javafx.beans.binding
>> - javafx.collections
>> - javafx.collections.transformation
>
> John Hendrikx has updated the pull request
simply expand and collapse the root note repeatedly
> while it has a child. Before the fix the graphic will disappear after a few
> tries, after the fix it won't. You can test other hierarchies as well by
> adding children to the tree.
Nir Lisker has updated the pull request incremental
On Tue, 3 Jan 2023 23:39:36 GMT, Andy Goryachev wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Added copyright header and changed package name
>
> tests/performance/check
simply expand and collapse the root note repeatedly
> while it has a child. Before the fix the graphic will disappear after a few
> tries, after the fix it won't. You can test other hierarchies as well by
> adding children to the tree.
Nir Lisker has updated the pull request incremental
On Tue, 3 Jan 2023 23:11:08 GMT, John Hendrikx wrote:
> Looks good to me, releasing the graphic for empty cells. I'm left wondering
> if it should also be releasing the bindings it makes in that case, although
> that's less likely to cause (visible) issues.
I could make that change. I don't
On Tue, 3 Jan 2023 23:07:19 GMT, Andy Goryachev wrote:
>> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
>> expand/collapse events. The graphics node needs to be released from the
>> previous checkbox so that it doesn't serve as the graphics of more than one
>>
On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker wrote:
> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
> expand/collapse events. The graphics node needs to be released from the
> previous checkbox so that it doesn't serve as the graphics of more than one
&
Vote: YES
On Tue, Jan 3, 2023 at 5:18 PM Kevin Rushforth
wrote:
> Vote: YES
>
> On 1/3/2023 7:17 AM, Kevin Rushforth wrote:
> > I hereby nominate John Hendrikx [1] to OpenJFX Committer.
>
>
On Sun, 1 Jan 2023 15:04:17 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/com/sun/javafx/binding/BidirectionalContentBinding.java
>> line 81:
>>
>>> 79: if ((obj1 instanceof ObservableList list1) && (obj2
>>> instanceof ObservableList list2)) {
>>> 80:
On Sun, 1 Jan 2023 15:23:16 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/javafx/collections/FXCollections.java line
>> 709:
>>
>>> 707: private static class EmptyObservableList extends
>>> AbstractList implements ObservableList {
>>> 708:
>>> 709: private static
On Tue, 6 Dec 2022 20:10:16 GMT, Nir Lisker wrote:
> A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
> expand/collapse events. The graphics node needs to be released from the
> previous checkbox so that it doesn't serve as the graphics of more than one
&
A simple fix for the graphics of a `CheckBoxTreeCell` not showing after
expand/collapse events. The graphics node needs to be released from the
previous checkbox so that it doesn't serve as the graphics of more than one
checkbox at once. If it does, only one checkbox (its skin) can actually use
We can do better than that. Instead of introducing methods for specific
operations, like concat and retain, we can offer bulk operations on
collections. When John H. proposed the fluent bindings additions, we
discussed doing the same for collections after that.
At the very least, we can have a
On Sun, 11 Dec 2022 20:12:17 GMT, John Hendrikx wrote:
> Packages fixed:
> - com.sun.javafx.binding
> - com.sun.javafx.collections
> - javafx.beans
> - javafx.beans.binding
> - javafx.collections
> - javafx.collections.transformation
Second part of the review. I'm still looking at the changes
On Mon, 26 Dec 2022 14:32:52 GMT, John Hendrikx wrote:
>> modules/javafx.base/src/main/java/javafx/beans/binding/ListExpression.java
>> line 238:
>>
>>> 236: public Iterator iterator() {
>>> 237: final ObservableList list = get();
>>> 238: return (list == null)?
>>>
On Sun, 11 Dec 2022 20:12:17 GMT, John Hendrikx wrote:
> Packages fixed:
> - com.sun.javafx.binding
> - com.sun.javafx.collections
> - javafx.beans
> - javafx.beans.binding
> - javafx.collections
> - javafx.collections.transformation
This is the first half of the review. Will finish the classes
On Thu, 1 Sep 2022 15:03:18 GMT, Ambarish Rapte wrote:
>> Nir Lisker has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Addressed review comment
>
> LGTM,
> suggested a minor correction in comment.
> I
oved the ambient color interpolation, which frees a register (no
> change in performance).
> * Simplified the structure (what is `LocalBumpOut` and why is it called
> `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
> * Moved the shader variant constants (`#ifndef`)
oved the ambient color interpolation, which frees a register (no
> change in performance).
> * Simplified the structure (what is `LocalBumpOut` and why is it called
> `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
> * Moved the shader variant constants (`#ifndef`)
On Sun, 25 Dec 2022 03:28:27 GMT, Nir Lisker wrote:
>> Refactoring and renaming changes to some of the D3D pipeline files and a few
>> changes on the Java side. These are various "leftovers" from previous issues
>> that we didn't want to touch at the time i
oved the ambient color interpolation, which frees a register (no
> change in performance).
> * Simplified the structure (what is `LocalBumpOut` and why is it called
> `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
> * Moved the shader variant constants (`#ifndef`)
://bugs.openjdk.org/browse/JDK-8119175
On Mon, Dec 12, 2022 at 6:10 PM Nir Lisker wrote:
> Another idea is to use a static map that maps a node to its "graphic
> parent". That will save on memory at the expense of a lookup.
>
> On Thu, Dec 1, 2022 at 11:53 PM Nir Lisker wrote:
oved the ambient color interpolation, which frees a register (no
> change in performance).
> * Simplified the structure (what is `LocalBumpOut` and why is it called
> `light` and contains `LocalBump`?).
> * `Mtl1PS` and `psMath`
> * Moved the shader variant constants (`#ifndef`)
On Thu, 1 Sep 2022 11:23:44 GMT, Nir Lisker wrote:
>> Refactoring and renaming changes to some of the D3D pipeline files and a few
>> changes on the Java side. These are various "leftovers" from previous issues
>> that we didn't want to touch at the time i
On Mon, 12 Dec 2022 22:42:16 GMT, John Hendrikx wrote:
>> This PR adds a new (lazy*) property on `Node` which provides a boolean which
>> indicates whether or not the `Node` is currently part of a `Scene`, which in
>> turn is part of a currently showing `Window`.
>>
>> It also adds a new
Another idea is to use a static map that maps a node to its "graphic
parent". That will save on memory at the expense of a lookup.
On Thu, Dec 1, 2022 at 11:53 PM Nir Lisker wrote:
> Are we convinced that a node can't be both a graphic and a clip, or
> something else? The docs
On Sun, 11 Dec 2022 20:31:24 GMT, John Hendrikx wrote:
>> This PR adds a new (lazy*) property on `Node` which provides a boolean which
>> indicates whether or not the `Node` is currently part of a `Scene`, which in
>> turn is part of a currently showing `Window`.
>>
>> It also adds a new
On Sun, 11 Dec 2022 14:30:22 GMT, John Hendrikx wrote:
>> - Added generics (to package private or internal classes only)
>> - Minor clean-ups of code I touched (naming)
>> - Fixed incorrect use of generics
>> - Fixed raw type warnings
>>
>> Note: some raw types have leaked into public API.
On Sat, 10 Dec 2022 08:23:07 GMT, John Hendrikx wrote:
>> - Added generics (to package private or internal classes only)
>> - Minor clean-ups of code I touched (naming)
>> - Fixed incorrect use of generics
>> - Fixed raw type warnings
>>
>> Note: some raw types have leaked into public API.
On Sat, 10 Dec 2022 08:18:34 GMT, John Hendrikx wrote:
>>> So... it's also a list.
>>
>> I think it's a big mess, you can already see that in the hierarchy,
>> extending both `ObservableObjectValue>` (which is
>> `ObservableValue`) but also being a `ObservableList`. One or the
>> other is
On Fri, 9 Dec 2022 20:11:24 GMT, John Hendrikx wrote:
>> I suggest the following method:
>>
>>
>> @Override
>> public boolean equals(Object obj) {
>> if (this == obj) {
>> return true;
>> }
>> if (!(obj instanceof List otherList)) {
>>
On Fri, 9 Dec 2022 18:35:57 GMT, John Hendrikx wrote:
>> It's safe as you're never actually using the type `E`, but I suppose the 2nd
>> list can also be `List` as only `equals` is called on it. The 2nd
>> `ListIterator` would then also be `ListIterator`.
>>
>> Casting to a specific generic
On Thu, 8 Dec 2022 14:21:45 GMT, John Hendrikx wrote:
>> - Added generics (to package private or internal classes only)
>> - Minor clean-ups of code I touched (naming)
>> - Fixed incorrect use of generics
>> - Fixed raw type warnings
>>
>> Note: some raw types have leaked into public API.
On Wed, 7 Dec 2022 13:25:47 GMT, Kevin Rushforth wrote:
>> - Added generics (to package private or internal classes only)
>> - Minor clean-ups of code I touched (naming)
>> - Fixed incorrect use of generics
>> - Fixed raw type warnings
>>
>> Note: some raw types have leaked into public API.
On Wed, 30 Nov 2022 12:55:08 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/UploadingPainter.java
>> line 41:
>>
>>> 39: * The PresentingPainter is used when we are rendering to the main
>>> screen.
>>> 40: */
>>> 41: final class
On Wed, 30 Nov 2022 12:48:10 GMT, Kevin Rushforth wrote:
>> If the casts in the numerator actually matter, then the cast in the
>> denominator can be removed. The latter are the ones that Eclipse flags for
>> me as unnecessary.
>
> I still think that any change here would be a very low value
On Mon, 5 Dec 2022 22:20:59 GMT, John Hendrikx wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix indentations and merge short lines
>
>> This is one giant pull request, somewhat difficult on the reviewers,
>>
On Tue, 6 Dec 2022 03:03:13 GMT, Andy Goryachev wrote:
>> The code was already broken (since 2014 apparently when the new Base64
>> decoder was used). Had the author turned on these handy warnings, they
>> would have noticed that something was amiss. Now they unwittingly changed
>> the
On Mon, 5 Dec 2022 20:17:04 GMT, Andy Goryachev wrote:
>> I do agree with @kevinrushforth here.
>>
>> It might be borderline useful to enable the warning once just to see if
>> there are any bugs or perhaps to clean up the most obvious cases, but it
>> probably makes little sense to enable
On Mon, 5 Dec 2022 21:40:40 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/font/PrismFontFile.java
>> line 586:
>>
>>> 584: ascent = -(float)hhea.getShort(4);
>>> 585: descent = -(float)hhea.getShort(6);
>>> 586:
On Mon, 5 Dec 2022 21:46:12 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/css/CssParser.java line 2579:
>>
>>> 2577: term = nextLayer(lastTerm);
>>> 2578: }
>>> 2579: return new ParsedValueImpl<>(layers,
>>>
I have been working with John on the effort to remove warnings, so
obviously I agree with these. I'd like to add a few points:
* There is flexibility in how to tell the comp[iler to mark these possible
problems. Some warnings can be turned into errors for stricter standards,
and I think that this
On Mon, 5 Dec 2022 10:50:56 GMT, Lukasz Kostyra wrote:
> The string was fixed to match other parameters' formatting.
>
> There was a PR submitted for this change a long time ago, but there were some
> issue with its previous author. Today I found the issue being assigned to me,
> so I figured
On Sat, 3 Dec 2022 20:54:04 GMT, John Hendrikx wrote:
>> - Remove unsupported/unnecessary SuppressWarning annotations
>> - Remove reduntant type specifications (use diamond operator)
>> - Remove unused or duplicate imports
>> - Remove unnecessary casts (type is already correct type or can be
On Fri, 2 Dec 2022 09:10:34 GMT, John Hendrikx wrote:
>> I didn't look too far for alternative names after I discovered `showing`
>> would not be possible. The name comes from `isTreeShowing` which is used
>> for a similar purpose (inside `Node`) and from `conditionOnShowing` in
>> ReactFX.
ralize the clipParent field to function for both (the ownedBy or owner
> field that I suggested earlier)?
>
> --John
> On 01/12/2022 20:26, Nir Lisker wrote:
>
> Michael's idea could solve the problem if it's about more than just
> traversing, it needs to set rules for allowing a nod
can do a quick fix for now that can be reverted later
if needed. From what I gather, I will need to add a graphicsParent field
like clipParent does.
On Thu, Dec 1, 2022 at 8:47 PM Nir Lisker wrote:
> By the way, these issues are caused by this inconsistent behavior (they
> are probably dupl
By the way, these issues are caused by this inconsistent behavior (they are
probably duplicates):
https://bugs.openjdk.org/browse/JDK-8209017
https://bugs.openjdk.org/browse/JDK-8190331
The graphic of the checkbox of a CheckBoxTreeItem is not set correctly on
the new CheckBox that is provided
On Thu, 1 Dec 2022 17:38:01 GMT, John Hendrikx wrote:
>> This PR adds a new (lazy*) property on `Node` which provides a boolean which
>> indicates whether or not the `Node` is currently part of a `Scene`, which in
>> turn is part of a currently showing `Window`.
>>
>> It also adds a new
On Fri, 29 Oct 2021 12:36:13 GMT, eduardsdv wrote:
> Create sources.jars and attach they to the publish task, so that they can be
> uploaded to the (e.g. maven) repository automatically.
It requires only 1 reviewer with the tole of Reviewer. One of you can be the
second reviewer.
in the scene graph, otherwise
> * the {@code IllegalArgumentException} is thrown. See the class
> * description of {@link Node} for more detail.
>
> --John
> On 01/12/2022 13:38, Nir Lisker wrote:
>
> That's my point. Currently, a node can serve as the graphics property for
;
> I think things are probably getting out of sync, where the graphics
> property may think it still has a certain node as its graphics, but it
> is no longer a child of the label.
>
> --John
>
> On 01/12/2022 11:23, Nir Lisker wrote:
> > Hi,
> >
> > Given
On Wed, 26 Oct 2022 07:56:52 GMT, John Hendrikx wrote:
>> This PR adds a new (lazy*) property on `Node` which provides a boolean which
>> indicates whether or not the `Node` is currently part of a `Scene`, which in
>> turn is part of a currently showing `Window`.
>>
>> It also adds a new
On Wed, 26 Oct 2022 06:52:17 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 1426:
>>
>>> 1424: if (s == null) return false;
>>> 1425: Window w = s.getWindow();
>>> 1426: return w != null && w.isShowing();
>>
>> Are you
Hi,
Given the following code
var cb1 = new Label("1");
var cb2 = new Label ("2");
var b1 = new Button("A");
cb1.setGraphic(b1);
b1.setOnAction(e -> {
if (b1.getParent() == cb1) {
// cb1.setGraphic(null);
On Tue, 22 Nov 2022 21:30:09 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix indentation
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
> line 418:
On Tue, 29 Nov 2022 17:11:51 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix indentation
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
> line 422:
On Tue, 29 Nov 2022 21:58:38 GMT, John Hendrikx wrote:
>> Note: I ran into a `javac` compiler bug while replacing types with diamond
>> operators (ecj has no issues). I had two options, add a
>> `SuppressWarnings("unused")` or to use a lambda instead of a method
>> reference to make `javac`
On Tue, 29 Nov 2022 18:37:23 GMT, Kevin Rushforth wrote:
>> interesting - there is technically no change, as `TableColumnBase`
>> implements `EventTarget`.
>> @hjohn does javadoc produce a different result?
>
> I checked, and yes it does produce a different result:
>
> Current:
>
>
> public
On Mon, 28 Nov 2022 17:04:17 GMT, John Hendrikx wrote:
>> - Remove unsupported/unnecessary SuppressWarning annotations
>> - Remove reduntant type specifications (use diamond operator)
>> - Remove unused or duplicate imports
>> - Remove unnecessary casts (type is already correct type or can be
On Tue, 22 Nov 2022 22:33:49 GMT, Kevin Rushforth wrote:
>> (long) width * height * 4;
>> is dangerous if one does not remember the precedence rules - is typecast
>> applied to width or the end result?
>> 4L * w * h; is unambiguous.
>
> I'm not sure I like either of the two choices you listed.
On Wed, 23 Nov 2022 07:26:31 GMT, John Hendrikx wrote:
>> Actually, I think the new code correct, though less clear, since `(long)` is
>> applied to `physicalWidth` before the multiplication. The fact that we had
>> to scratch our head and discuss it highlights the point I was trying to
>>
On Tue, 22 Nov 2022 18:39:43 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Wed, 23 Nov 2022 23:06:45 GMT, John Hendrikx wrote:
>> modules/javafx.controls/src/test/java/test/com/sun/javafx/scene/control/infrastructure/ControlSkinFactory.java
>> line 287:
>>
>>> 285: .map(d -> new Object[] {d, })
>>> 286: .collect(toList());
>>> 287:
On Thu, 24 Nov 2022 00:12:04 GMT, Andy Goryachev wrote:
> It makes no sense to enable the warning and not fix all the warnings in the
> code. I would like to see 0 warnings in the problem list.
The warning is for all unnecessary casts, which removes a lot of clutter. If,
in some special
On Tue, 22 Nov 2022 18:39:43 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Tue, 22 Nov 2022 18:54:39 GMT, John Hendrikx wrote:
>> Note: I ran into a `javac` compiler bug while replacing types with diamond
>> operators (ecj has no issues). I had two options, add a
>> `SuppressWarnings("unused")` or to use a lambda instead of a method
>> reference to make `javac`
On Tue, 22 Nov 2022 19:04:00 GMT, Kevin Rushforth wrote:
>> Not needed in the setup, if it is `null` later or throws an exception the
>> test failure is clear enough.
>>
>> Also a bit out of scope of this PR.
>
> Yes, adding an assert does seem out of scope of this PR, although Andy
> comment
On Tue, 22 Nov 2022 18:54:39 GMT, John Hendrikx wrote:
>> Note: I ran into a `javac` compiler bug while replacing types with diamond
>> operators (ecj has no issues). I had two options, add a
>> `SuppressWarnings("unused")` or to use a lambda instead of a method
>> reference to make `javac`
On Tue, 22 Nov 2022 18:48:41 GMT, John Hendrikx wrote:
>> modules/javafx.controls/src/main/java/com/sun/javafx/scene/control/skin/FXVKSkin.java
>> line 858:
>>
>>> 856: protected void sendKeyEvents() {
>>> 857: Node target = fxvk.getAttachedNode();
>>> 858:
>>
>> same
On Tue, 22 Nov 2022 18:52:32 GMT, John Hendrikx wrote:
>> modules/javafx.fxml/src/main/java/javafx/fxml/FXMLLoader.java line 1446:
>>
>>> 1444: @Override
>>> 1445: public void processEndElement() throws IOException {
>>> 1446: super.processEndElement();
>>
>> I
On Tue, 22 Nov 2022 16:43:06 GMT, John Hendrikx wrote:
>> - Remove unsupported/unnecessary SuppressWarning annotations
>> - Remove reduntant type specifications (use diamond operator)
>> - Remove unused or duplicate imports
>> - Remove unnecessary casts (type is already correct type or can be
On Tue, 22 Nov 2022 16:49:52 GMT, John Hendrikx wrote:
>> - Remove unsupported/unnecessary SuppressWarning annotations
>> - Remove reduntant type specifications (use diamond operator)
>> - Remove unused or duplicate imports
>> - Remove unnecessary casts (type is already correct type or can be
On Tue, 22 Nov 2022 11:13:40 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Mon, 21 Nov 2022 22:28:15 GMT, Kevin Rushforth wrote:
> treating certain categories of warnings as errors at compilation time is
> quite feasible. The JDK does this.
I have "missing override annotations" set to errors in my projects. I think
it's a good candidate here.
-
PR:
My proposal in the PR was 'updateWhen', which I prefer over observedWhen
and activeWhen. Just 'when' is also fine by me and prefered over 'when'.
My only problem with 'when'/'whenever' is that they don't say what happens
"when"/"whenever". However, since these are bindings, and what bindings do
On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Mon, 21 Nov 2022 20:49:07 GMT, Andy Goryachev wrote:
>> but the ticket specifies (javafx.)base, right?
>
> let's create a followup ticket - the messed up statements in Disposer and
> especially in PrismFontFactory:1401 are worrying.
>
> cc: @prrace
All of the bugs in the list are not in
On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
On Mon, 21 Nov 2022 15:19:24 GMT, Kevin Rushforth wrote:
> The main thing to be careful of is that we don't touch any public API
> signatures, since some of these sort of automated changes can have impact
> that we would need to consider.
This set of warnings doesn't change method signatures.
On Mon, 21 Nov 2022 11:53:30 GMT, John Hendrikx wrote:
> - Remove unsupported/unnecessary SuppressWarning annotations
> - Remove reduntant type specifications (use diamond operator)
> - Remove unused or duplicate imports
> - Remove unnecessary casts (type is already correct type or can be
Hi,
Another issue I stumbled across is the usage of the Independent property
on CheckBoxTreeItem. The docs read:
A BooleanProperty used to represent the independent state of this
> CheckBoxTreeItem. The independent state is used to represent whether
> changes to a single CheckBoxTreeItem should
I think that even if a node is set to indeterminate programmatically, its
parents should be updated at the very least (unless it's set to be
independent). Not updating the children seems reasonable.
On Fri, Nov 18, 2022 at 11:12 AM John Hendrikx
wrote:
>
> On 18/11/2022 00:10, Nir Lisker
Hi,
I have been working on fixing some issues with the behavior
of CheckBoxTreeItem. I stumbled across this situation:
When a parent is de/selected, all of its children are set to the same
state. However, a CheckBoxTreeItem can be set to indeterminate
programmatically (the control itself does
(lucene).
>
>
>
> Perhaps we should also add a section dedicated to configuring error
> levels, as the default configuration turns off important warnings and
> enables too many unimportant ones.
>
>
>
> Thank you again
>
> -andy
>
>
>
>
>
>
>
On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx wrote:
>> See https://bugs.openjdk.org/browse/JDK-8221708
>
> John Hendrikx has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix controls classpath
I updated
Is https://bugs.openjdk.org/browse/JDK-8275033 related?
On Tue, Nov 15, 2022 at 2:14 AM Thiago Milczarek Sayão <
thiago.sa...@gmail.com> wrote:
> I took a look at it, and It seems "by design".
> Child stages can be larger, it just can't cover the desktop bar.
> If you run in a kiosk style setup
On Sun, 13 Nov 2022 02:27:55 GMT, John Hendrikx wrote:
>> See https://bugs.openjdk.org/browse/JDK-8221708
>
> John Hendrikx has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Fix controls classpath
Marked as reviewed by nlisker (Reviewer).
On Sun, 13 Nov 2022 01:43:30 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove unnecessary add-exports attribute from Eclipse files
>
> tests/manual/deskto
On Sat, 12 Nov 2022 20:38:49 GMT, John Hendrikx wrote:
>> See https://bugs.openjdk.org/browse/JDK-8221708
>
> John Hendrikx has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Remove unnecessary add-exports attribute from Eclipse files
On Mon, 7 Nov 2022 08:32:22 GMT, John Hendrikx wrote:
>> See https://bugs.openjdk.org/browse/JDK-8221708
>
> John Hendrikx has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Update Eclipse classpath files
>
> - Stripped dependencies to a
On Mon, 7 Nov 2022 16:29:42 GMT, Ambarish Rapte wrote:
>> This issue was uncovered when running the test added in PR:
>> https://github.com/openjdk/jfx/pull/910
>> The JUnit5 tests using Params API fails to compile.
>>
>> Fix:
>> Change dependency of `junit-jupiter-params` from runtime to
Vote: YES
On Mon, Nov 7, 2022 at 11:19 AM Ajit Ghaisas
wrote:
> Vote : Yes
>
> Regards,
> Ajit
>
> > On 03-Nov-2022, at 10:35 PM, Kevin Rushforth
> wrote:
> >
> > I hereby nominate Andy Goryachev [1] to OpenJFX Committer.
> >
> > Andy is a member of the JavaFX team at Oracle who has
On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote:
> See https://bugs.openjdk.org/browse/JDK-8221708
The new changes look good. I get a bogus error marker on the apps folder in
Project Explorer, but in Package Explorer there is no error. Looks like some
Eclipse hiccup.
My only comment is
On Sat, 22 Oct 2022 07:49:12 GMT, John Hendrikx wrote:
> See https://bugs.openjdk.org/browse/JDK-8221708
Alright, we'll go with option 2 then and keep option 3 for further research.
The new changes look fine, I'll do a formal review soon.
-
PR:
On Wed, 26 Oct 2022 23:20:30 GMT, Kevin Rushforth wrote:
>> .project line 3:
>>
>>> 1:
>>> 2:
>>> 3: jfx
>>
>> this may cause issues with internal setup at oracle
>
> We do still clone the repo into a directory named `rt` when doing a closed
> build, but I doubt this change will cause
On Fri, 28 Oct 2022 21:18:54 GMT, Nir Lisker wrote:
>>> but that's another issue for another time.
>>
>> I respectfully disagree - the initial import (with all the documented extra
>> steps) should result in a clean state - as it is currently with the master
&
401 - 500 of 1528 matches
Mail list logo
