Integrated: 8275815: OCA link in README.md and CONTRIBUTING.md is broken
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/ This pull request has now been integrated. Changeset: d244b305 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/d244b3054aa3a735825c360159826bc414df36ca Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8275815: OCA link in README.md and CONTRIBUTING.md is broken Reviewed-by: nlisker - PR: https://git.openjdk.java.net/jfx/pull/652
Re: RFR: Draft: 8274274: Update JavaFX test framework to JUnit 5 [v5]
On Sat, 25 Sep 2021 13:55:15 GMT, John Hendrikx wrote: >> I've added JUnit 5 as a test dependency and made sure that the JUnit 4 tests >> still work. Also added a single JUnit 5 tests, and confirmed it works. >> >> I've updated the Eclipse project file for the base module only. > > John Hendrikx has updated the pull request incrementally with one additional > commit since the last revision: > > Readd junit declaration in allprojects and set junit version to 4.13.2 It looks like I spoke too soon. I am informed there is still another needed step. - PR: https://git.openjdk.java.net/jfx/pull/633
Re: RFR: 8275815: OCA link in README.md and CONTRIBUTING.md is broken
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: https://git.openjdk.java.net/jfx/pull/652
Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v9]
> The inconsistent illumination happens on Macs with retina displays only if > the 3D shape is placed in a SubScene. The light sources are located with > wrong coordinates in sub scenes and this causes a different illumination. The > wrong coordinates for the light sources come from the fact that the retina > pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in > SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: 8255015: Comment about copying pixel scale factors corrected - Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/b0b6c13b..280ae78c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=08 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=07-08 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531
RFR: 8275815: OCA link in README.md and CONTRIBUTING.md is broken
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/ - Commit messages: - 8275815: OCA link in README.md and CONTRIBUTING.md is broken Changes: https://git.openjdk.java.net/jfx/pull/652/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=652&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8275815 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/652.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/652/head:pull/652 PR: https://git.openjdk.java.net/jfx/pull/652
RFR: 8227371: Drag&Drop while holding the CMD key does not work on macOS
During a drag-and-drop operation on the Mac the Command key will filter out every drag source operation except `NSDragOperationGeneric` (this behavior is provided by the OS). JavaFX drag sources only set the Move, Copy, and Link drag operation bits so the Command key reduces the set of available operations to nothing. This PR changes nothing about how JavaFX behaves when the dnd operation involves an external application. As a drag source the same set of operations will be broadcast and as a drag destination the operations will be interpreted as they have always been. For internal dnd within the JavaFX app `NSDragOperationMove` and `NSDragOperationGeneric` will both be set if the drag source specifies `TransferMode.MOVE`. On the other end a drag destination will interpret `NSDragOperationGeneric` and `NSDragOperationMove` as synonyms. As part of this PR it was necessary to verify that `NSDragOperationGeneric` was not already being used during an internal drag operation. There's a clause in `mapJavaMaskToNsOperation:` which translates `com_sun_glass_ui_Clipboard_ACTION_ANY` to `NSDragOperationEvery` and this includes the Generic bit. I believe this is a red herring, the Java dnd code converts `TransferMode.ANY` to a bitwise-OR of COPY, MOVE, and REFERENCE so `com_sun_glass_ui_Clipboard_ACTION_ANY` will never be passed down to the platform level. - Commit messages: - 8227371 Drag&Drop while holding the CMD key does not work on macOS Changes: https://git.openjdk.java.net/jfx/pull/651/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=651&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8227371 Stats: 87 lines in 3 files changed: 78 ins; 1 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/651.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/651/head:pull/651 PR: https://git.openjdk.java.net/jfx/pull/651
Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v8]
> The inconsistent illumination happens on Macs with retina displays only if > the 3D shape is placed in a SubScene. The light sources are located with > wrong coordinates in sub scenes and this causes a different illumination. The > wrong coordinates for the light sources come from the fact that the retina > pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in > SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: 8255015: Tabs removed from PointLightIllumination.java - Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/4168f5f3..b0b6c13b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=07 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=06-07 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531
Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v7]
> The inconsistent illumination happens on Macs with retina displays only if > the 3D shape is placed in a SubScene. The light sources are located with > wrong coordinates in sub scenes and this causes a different illumination. The > wrong coordinates for the light sources come from the fact that the retina > pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in > SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'openjdk:master' into fix-8255015 - 8255015: JUnit Test class added. - Merge branch 'openjdk:master' into fix-8255015 - Merge branch 'openjdk:master' into fix-8255015 - Merge branch 'openjdk:master' into fix-8255015 - 8255015: Copy pixel scale factors from graphics object to subscene graphics so that the position of lights will be scaled correctly on retina displays - Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/3e1af1c3..4168f5f3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=06 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=05-06 Stats: 4396 lines in 237 files changed: 3132 ins; 530 del; 734 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531
Re: RFR: 8271090: Missing API docs in scenegraph classes
On Fri, 22 Oct 2021 14:35:23 GMT, Nir Lisker 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 still few remaining warnings in these modules. The root cause is
>> different and they will be addressed under
>> [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 91:
>
>> 89: * Default size of the {@code Box}.
>> 90: */
>> 91: public static final double DEFAULT_SIZE = 2;
>
> This field was exposed by mistake probably. The other shapes don't expose
> theirs. I recommend to deprecate for removal.
Agreed. That would need to be done in a follow-up issue, and with a CSR. So
just revert this addition for this PR.
-
PR: https://git.openjdk.java.net/jfx/pull/650
Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v6]
> The inconsistent illumination happens on Macs with retina displays only if > the 3D shape is placed in a SubScene. The light sources are located with > wrong coordinates in sub scenes and this causes a different illumination. The > wrong coordinates for the light sources come from the fact that the retina > pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in > SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8255015: JUnit Test class added. - Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/a3677124..3e1af1c3 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=04-05 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531
Re: RFR: 8271090: Missing API docs in scenegraph classes
On Fri, 22 Oct 2021 14:48:31 GMT, Nir Lisker 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 still few remaining warnings in these modules. The root cause is
>> different and they will be addressed under
>> [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> modules/javafx.graphics/src/main/java/javafx/scene/Camera.java line 164:
>
>> 162: /**
>> 163: * Creates a {@code Camera}.
>> 164: */
>
> Sine the constructor is a `protected` for an `abstract` class, it doesn't
> create a `Camera` in the normal sense of constructors. I would write
> something like "Shared constructor for subclasses of `Camera`".
Good catch. We've started using "Constructor for subclasses to call." as the
description of such classes. See PR #283 for example.
-
PR: https://git.openjdk.java.net/jfx/pull/650
Re: RFR: 8271090: Missing API docs in scenegraph classes
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 still few remaining warnings in these modules. The root cause is
> different and they will be addressed under
> [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
I left two comments below.
modules/javafx.graphics/src/main/java/javafx/stage/Stage.java line 1307:
> 1305: * @return the full screen exit hint property
> 1306: * @since JavaFX 8.0
> 1307: */
Instead of this change, I recommend moving the docs that are currently on the
getter to the private `fullScreenExitHint` field. As mentioned in the review
for PR #646 the best practice is that exactly one of the private field or the
property method should have docs, and that the getter and setter should have no
docs (absent a compelling reason).
modules/javafx.graphics/src/main/java/javafx/stage/Window.java line 781:
> 779: * Sets the {@code Scene} of this {@code Window}.
> 780: * @param value the {@code Scene} to be set
> 781: */
The javadoc tool automatically generates docs for this setter (you can see this
from the generated docs without this change), including the property
description, so this change will actually lose information. I'm guessing that
the tool warns on this method because the setter is protected (rather than
public). So we should probably file a bug against the javadoc tool. As for how
to fix it, you can either suppress the warning (I'm not sure whether that's
possible), or you can copy the information from the property method with a
leading sentence that matches what javadoc _would_ generate.
-
PR: https://git.openjdk.java.net/jfx/pull/650
Re: RFR: 8255015: Inconsistent illumination of 3D shape by PointLight [v5]
> The inconsistent illumination happens on Macs with retina displays only if > the 3D shape is placed in a SubScene. The light sources are located with > wrong coordinates in sub scenes and this causes a different illumination. The > wrong coordinates for the light sources come from the fact that the retina > pixel scale factors are not used in a SubScene. > > With this pull request, the retina pixel scale factors will be also used in > SubScenes and this should resolve the bug > [https://bugs.openjdk.java.net/browse/JDK-8255015](url) Andreas Heger has updated the pull request incrementally with one additional commit since the last revision: JUnit Test class for verifying JDK-8255015 added. - Changes: - all: https://git.openjdk.java.net/jfx/pull/531/files - new: https://git.openjdk.java.net/jfx/pull/531/files/c7e58901..a3677124 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=531&range=03-04 Stats: 180 lines in 1 file changed: 180 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/531.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/531/head:pull/531 PR: https://git.openjdk.java.net/jfx/pull/531
Re: RFR: 8271090: Missing API docs in scenegraph classes
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 still few remaining warnings in these modules. The root cause is
> different and they will be addressed under
> [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
modules/javafx.graphics/src/main/java/javafx/scene/Camera.java line 164:
> 162: /**
> 163: * Creates a {@code Camera}.
> 164: */
Sine the constructor is a `protected` for an `abstract` class, it doesn't
create a `Camera` in the normal sense of constructors. I would write something
like "Shared constructor for subclasses of `Camera`".
modules/javafx.graphics/src/main/java/javafx/scene/paint/Material.java line 81:
> 79: /**
> 80: * Creates a {@code Material}.
> 81: */
Same comment as in `Camera`.
modules/javafx.graphics/src/main/java/javafx/scene/shape/Box.java line 91:
> 89: * Default size of the {@code Box}.
> 90: */
> 91: public static final double DEFAULT_SIZE = 2;
This field was exposed by mistake probably. The other shapes don't expose
theirs. I recommend to deprecate for removal.
modules/javafx.graphics/src/main/java/javafx/scene/shape/Shape3D.java line 102:
> 100: /**
> 101: * Creates a {@code Shape3D}.
> 102: */
Same comment as in `Camera`,
modules/javafx.media/src/main/java/javafx/scene/media/Track.java line 85:
> 83: /**
> 84: * Gets the Map containing all known metadata for this
> Track.
> 85: * @return the Map containing all known metadata for
> this Track
We tend to use `{@code }` over ` `, but I don't think it matter.
-
PR: https://git.openjdk.java.net/jfx/pull/650
Re: RFR: 8271091: Missing API docs in UI controls classes [v2]
On Thu, 21 Oct 2021 08:58:37 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 warnings remaining in javafx.web module. The root cause is different
>> and they will be addressed under
>> [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996)
>
> Ajit Ghaisas has updated the pull request incrementally with one additional
> commit since the last revision:
>
> javadoc minor corrections
See comments below.
modules/javafx.controls/src/main/java/javafx/scene/control/DatePicker.java line
470:
> 468: * {@code CssMetaData} of its superclasses.
> 469: * @return the {@code CssMetaData}
> 470: * @since JavaFX 8.0
The class already has an `@since JavaFX 8.0` tag so this is unnecessary. It's
also unrelated to this fix (and we would need a CSR for any changes to `@since`
tags).
modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java
line 160:
> 158: /**
> 159: * Focuses the item at the given index.
> 160: * @param index the index of the item that needs to be focused
Minor: I recommend removing "that needs" from this `@param`.
modules/javafx.controls/src/main/java/javafx/scene/control/PopupControl.java
line 201:
> 199: * this specific {@code PopupControl}.
> 200: * @return the {@code StringProperty} representing the CSS style
> 201: */
I recommend taking the information from the setter and copying it here. The
docs can/should then be removed from both the setter and the getter. The first
sentence should describe the property so does not need to start with "Gets the
...". You can add the information about `null` being turned into the empty
string as a sentence in the Description. The `@defaultValue empty string` means
that the information in the `@return` of the getter is unnecessary.
modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line
47:
> 45: /**
> 46: * Gets the default singleton {@code SortEvent}.
> 47: * @param the type of control
Can you also add this `@param` tag to the class description? I'm a little
surprised that javadoc doesn't flag it as missing.
modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line
59:
> 57: /**
> 58: * Constructs a new {@code Event} with the specified event source,
> target
> 59: * and type. If the source or target is set to {@code null}, it is
> replaced
That should be "a new `{@code SortEvent}` ...". Also, since there is no type
parameter, you should remove "and type" (and replace the comma after source
with "and").
modules/javafx.controls/src/main/java/javafx/scene/control/SortEvent.java line
63:
> 61: *
> 62: * @param source the event source which sent the event
> 63: * @param target the target of the scroll to operation
That should be "the target of the event".
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
405:
> 403: }
> 404:
> 405: public final DoubleProperty tabMaxWidthProperty() {
The best practice for properties is to put the description on exactly one of
the `xxx` private field or the `xxxProperty` method, and not on the setter or
getter (unless there is a specific need to document something special in the
setter or getter). There is a separate JBS issue,
[JDK-8271085](https://bugs.openjdk.java.net/browse/JDK-8271085), tracking the
fix for the `maxWidth` and `maxHeight` properties.
You can either revert this change, in which case we'll need a new PR for that
issue (it can be done later), or else modify this change to match the best
practice as noted in JDK-8271085 and add that issue to this PR. The latter will
require addressing the other methods in this file as noted in that JBS bug.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
501:
> 499: }
> 500:
> 501: public final DoubleProperty tabMaxHeightProperty() {
Same comment as above. This needs to be reverted or modified.
modules/javafx.controls/src/main/java/javafx/scene/control/TreeTableColumn.java
line 625:
> 623: * Gets the {@code CssMetaData} associated with this class, which
> may include the
> 624: * {@code CssMetaData} of its superclasses.
> 625: * @return empty list is returned as of now
Minor: I recommend adding a second sentence to the Description to the effect
that it is currently an empty list, and then have the return tag be simply
`@return an empty list`
modules/javafx.controls/src/main/java/javafx/scene/control/skin/TextInputControlSkin.java
line 118:
> 116: /** Line unit */ LINE,
> 117: /** Paragraph unit */ PARAGRAPH,
> 118: /** Page unit */ PAGE };
I would prefer that the javadoc tag and the enum be on separate lines.
/** Characte
RFR: 8271090: Missing API docs in scenegraph classes
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 still few remaining warnings in these modules. The root cause is different and they will be addressed under [JDK-8270996](https://bugs.openjdk.java.net/browse/JDK-8270996) - Commit messages: - 8271090 - fix javadoc warnings - base,media,fxml - 8271090 - fix javadoc warnings Changes: https://git.openjdk.java.net/jfx/pull/650/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=650&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271090 Stats: 107 lines in 29 files changed: 74 ins; 0 del; 33 mod Patch: https://git.openjdk.java.net/jfx/pull/650.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/650/head:pull/650 PR: https://git.openjdk.java.net/jfx/pull/650
Re: RFR: 8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit [v3]
> cell startEdit is supposed to update the editing location on its associated > control - was done in ListCell, not in Tree-/TableCell nor TreeCell. > > Fix was to add control.edit(..). Note that ListCell was also touched to use > the exact same method call pattern as the fixed cell types. > > Added/unignored cell tests that are failing/passing before/after the fix. Jeanette Winzenburg has updated the pull request incrementally with one additional commit since the last revision: next try with fixing the formatting - Changes: - all: https://git.openjdk.java.net/jfx/pull/638/files - new: https://git.openjdk.java.net/jfx/pull/638/files/4f76e1fe..4fd55ffa Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=638&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/638.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/638/head:pull/638 PR: https://git.openjdk.java.net/jfx/pull/638
Re: RFR: 8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit [v2]
On Fri, 22 Oct 2021 10:15:59 GMT, Jeanette Winzenburg wrote: >> darn .. ;) Thanks > > hmm .. I'm all for consistency, so don't mind trying again but ... what _is_ > the formatting rule? Searching in controls: > > - wildcard search: `` = 1000+ vs. `` = 379 > - verbatim: `` = 173 vs. `` = 98 > > Looks .. inconclusive .. 😁? > > But then, [generics > tutorial](https://docs.oracle.com/javase/tutorial/java/generics/types.html) > has the space - so the space it will be. Weird. Also standard classes like HashMap, AbstractMap or just Map doesn't have the space. I'm also for consisteny, but don't know which would be 'the best' 😄 - PR: https://git.openjdk.java.net/jfx/pull/638
Re: RFR: 8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit [v2]
On Fri, 22 Oct 2021 09:45:10 GMT, Jeanette Winzenburg wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java >> line 548: >> >>> 546: int editingRow = 1; >>> 547: cell.updateIndex(editingRow); >>> 548: TablePosition editingCell = new TablePosition<>(table, >>> editingRow, editingColumn); >> >> Just saw you added the space for the `` in line 559 (which I didn't saw >> 😄) but not here :) > > darn .. ;) Thanks hmm .. I'm all for consistency, so don't mind trying again but ... what _is_ the formatting rule? Searching in controls: - wildcard search: `` = 1000+ vs. `` = 379 - verbatim: `` = 173 vs. `` = 98 Looks .. inconclusive .. 😁? - PR: https://git.openjdk.java.net/jfx/pull/638
Re: RFR: 8187474: Tree-/TableCell, TreeCell: editingCell/Item not updated in cell.startEdit [v2]
On Thu, 21 Oct 2021 18:50:45 GMT, Marius Hanl wrote: >> Jeanette Winzenburg has updated the pull request incrementally with one >> additional commit since the last revision: >> >> fixed formatting as suggested in review >> >> and removed unused (by this fix) import in same file > > modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java > line 548: > >> 546: int editingRow = 1; >> 547: cell.updateIndex(editingRow); >> 548: TablePosition editingCell = new TablePosition<>(table, >> editingRow, editingColumn); > > Just saw you added the space for the `` in line 559 (which I didn't saw > 😄) but not here :) darn .. ;) Thanks - PR: https://git.openjdk.java.net/jfx/pull/638
