it :))
-- Marius
GESENDET: Freitag, 11. Februar 2022 um 18:03 Uhr
VON: "Jeanette Winzenburg"
AN: "openjfx-dev"
BETREFF: Sneak preview: cell edit api to support commit-on-focusLost
Hi folks,
after fixing a bunch of edit-related issues, time feels right for
nudging elep
Hi folks,
after fixing a bunch of edit-related issues, time feels right for
nudging elephant out of the room :) Which is the bigger goal of
supporting commit-on-focusLost.
Working on a PoC (ListView/-Cell only) in a branch of my fork
On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg
wrote:
> Issue was TreeView commit editing implementation violated the spec'ed
> mechanism:
>
> - no default commit handler on TreeView
> - TreeCell modifying the data directly
>
> Fix is to move the saving of the e
On Tue, 8 Feb 2022 12:49:59 GMT, Marius Hanl wrote:
>> Issue was TreeView commit editing implementation violated the spec'ed
>> mechanism:
>>
>> - no default commit handler on TreeView
>> - TreeCell modifying the data directly
>>
>> Fix is to move the saving of the edited value from cell into
On Wed, 9 Feb 2022 10:51:54 GMT, Ajit Ghaisas wrote:
>> Issue was TreeView commit editing implementation violated the spec'ed
>> mechanism:
>>
>> - no default commit handler on TreeView
>> - TreeCell modifying the data directly
>>
>> Fix is to move the saving of the edited value from cell
On Thu, 3 Feb 2022 11:38:55 GMT, Jeanette Winzenburg
wrote:
> the issue was commented asserts in a test methods - they had been failing due
> to incorrect usage of registering an edit commit handler
>
> fix was to correct the registration and uncomment the assert (ListViewTest).
the issue was commented asserts in a test methods - they had been failing due
to incorrect usage of registering an edit commit handler
fix was to correct the registration and uncomment the assert (ListViewTest).
For Tree/TableViewTest, had to adjust value access also (was: c from
Issue was TreeView commit editing implementation violated the spec'ed mechanism:
- no default commit handler on TreeView
- TreeCell modifying the data directly
Fix is to move the saving of the edited value from cell into a default commit
handler in tree and set that handler in the constructor.
On Tue, 1 Feb 2022 17:41:47 GMT, Marius Hanl wrote:
>> This PR will fix a simple NPE which may happens when using the `TableRow`
>> inside a `TableCell` during the initial auto sizing.
>> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()`
>> will return null and it is not
of the bug if needed.
-- Kevin
On 1/31/2022 6:57 AM, Jeanette Winzenburg wrote:
Currently working on two related issues:
https://bugs.openjdk.java.net/browse/JDK-8187309: TreeCell must not
change data of treeView
https://bugs.openjdk.java.net/browse/JDK-8187473: TreeView must
have default commit
Currently working on two related issues:
https://bugs.openjdk.java.net/browse/JDK-8187309: TreeCell must not
change data of treeView
https://bugs.openjdk.java.net/browse/JDK-8187473: TreeView must have
default commit handler
which are so intertwined that there's no way to fix one without
On Thu, 27 Jan 2022 20:38:56 GMT, Marius Hanl wrote:
>> This PR will fix a simple NPE which may happens when using the `TableRow`
>> inside a `TableCell` during the initial auto sizing.
>> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()`
>> will return null and it is
On Fri, 28 Jan 2022 13:14:37 GMT, Marius Hanl wrote:
>> just curious: why didn't you move the tests into TableColumnHeaderTest?
>
> I had no particular reason, I think the test fits both classes, although
> `TableColumnHeaderTest` just tests the normal `TableView`. So I kept it in
> the
On Thu, 27 Jan 2022 10:21:18 GMT, Marius Hanl wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableCellTest.java
>> line 371:
>>
>>> 369: @Test
>>> 370: public void testRowIsNotNullWhenAutoSizing() {
>>> 371: TableColumn tableColumn = new
On Thu, 27 Jan 2022 20:48:40 GMT, Marius Hanl wrote:
>> When a divider is moved via drag or code it will call **requestLayout()**
>> for the **SplitPane**.
>> While this is fine, it is also called when the
>> **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider.
>>
>> This
On Thu, 27 Jan 2022 11:42:28 GMT, Marius Hanl wrote:
>>> Hm, is this really needed?
>>
>> yes, IMO, we want the exact same cleanup for passing/failing tests. So
>> either dispose is required always (then need to make sure it's called on
>> failure) or not required always (then all its calls
On Wed, 26 Jan 2022 20:14:37 GMT, Marius Hanl wrote:
> Hm, is this really needed?
yes, IMO, we want the exact same cleanup for passing/failing tests. So either
dispose is required always (then need to make sure it's called on failure) or
not required always (then all its calls would be
On Mon, 22 Nov 2021 14:03:56 GMT, Marius Hanl wrote:
>> When a divider is moved via drag or code it will call **requestLayout()**
>> for the **SplitPane**.
>> While this is fine, it is also called when the
>> **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider.
>>
>> This
On Fri, 14 Jan 2022 00:04:49 GMT, Marius Hanl wrote:
> This PR will fix a simple NPE which may happens when using the `TableRow`
> inside a `TableCell` during the initial auto sizing.
> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will
> return null and it is not
with (too many) other
things.
I'll fix up the JBS records.
Thanks.
-- Kevin
On 1/20/2022 4:13 AM, Jeanette Winzenburg wrote:
wondering what happened in https://github.com/openjdk/jfx/pull/684
(fix for https://bugs.openjdk.java.net/browse/JDK-8187307)
- requested integration
wondering what happened in https://github.com/openjdk/jfx/pull/684
(fix for https://bugs.openjdk.java.net/browse/JDK-8187307)
- requested integration (into master) after review approval
- the bots did the usual thingies (commit, comment/close the issue in jbs)
- the bots did some unusual
On Tue, 30 Nov 2021 12:32:37 GMT, Jeanette Winzenburg
wrote:
> The misbehaviour was that an edit handler received both a commit and cancel
> event when cell commitEdit is called. That happened whenever a collaborator
> reset the controls editing state (either directly or indirect
GESENDET: Dienstag, 18. Januar 2022 um 15:46 Uhr
VON: "Jeanette Winzenburg"
AN: "openjfx-dev"
BETREFF: Strange test failures: validation of PGGroup children failed
Just stumbled across it while reviewing PR 719
(https://github.com/openjdk/jfx/pull/716)
- added the new tes
Just stumbled across it while reviewing PR 719
(https://github.com/openjdk/jfx/pull/716)
- added the new test method to see it fail (which it does)
- run all control tests throws the error below in _unrelated_ tests
(the one below is from TableCellTest, that is the same test the new
On Fri, 14 Jan 2022 00:04:49 GMT, Marius Hanl wrote:
> This PR will fix a simple NPE which may happens when using the `TableRow`
> inside a `TableCell` during the initial auto sizing.
> In the auto sizing code, no `TableRow` is set, therefore `getTableRow()` will
> return null and it is not
On Thu, 9 Dec 2021 12:43:54 GMT, Jeanette Winzenburg
wrote:
> Extracted static test utility methods from EditAndScrollTest into new
> VirtualizedControlTestUtils, added rudimentary tests for the methods.
This pull request has now been integrated.
Changeset: 002d4f57
Author:Je
> Extracted static test utility methods from EditAndScrollTest into new
> VirtualizedControlTestUtils, added rudimentary tests for the methods.
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last revision:
fixed c error
On Thu, 16 Dec 2021 11:00:39 GMT, Ajit Ghaisas wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> fixed c error in doc
>
> modules/javafx.controls/src/test/java/test/com/sun/javaf
On Tue, 7 Dec 2021 15:44:26 GMT, Michael Strauß wrote:
>However, I'd still argue that a node that is not part of the scene graph
>(non-atomically) should not be the focus owner of the scene graph.
I agree :)
But that's what seems to happen: in my example, add a handler to remove the
focused
Extracted static test utility methods from EditAndScrollTest into new
VirtualizedControlTestUtils, added rudimentary tests for the methods.
-
Commit messages:
- 8278134: Move static utility methods to infrastructure
Changes: https://git.openjdk.java.net/jfx/pull/690/files
Webrev:
On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strauß wrote:
>> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as
>> well as the corresponding `:focus-visible` and `:focus-within` CSS
>> pseudo-classes.
>
> Michael Strauß has updated the pull request incrementally with one
On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strauß wrote:
>> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as
>> well as the corresponding `:focus-visible` and `:focus-within` CSS
>> pseudo-classes.
>
> Michael Strauß has updated the pull request incrementally with one
On Mon, 2 Aug 2021 13:20:29 GMT, Michael Strauß wrote:
> > 3. I think the way you are propagating `focusWithin` might not work if
> > nodes are added or removed from the scene graph.
>
> I've added a test for this case:
> `FocusTest.testFocusStatesAreClearedFromFormerParentsOfFocusedNode`.
On Mon, 6 Dec 2021 09:23:53 GMT, eduardsdv wrote:
> I tested it again. Without the changes in this PR the bug is still there.
> **If the item is larger than the viewport**, the VirtualFlow.scrollToTop(int)
> scrolls to the end instead of to top of the item.
ahhh .. finally I understand what
On Thu, 25 Nov 2021 15:46:01 GMT, Jeanette Winzenburg
wrote:
> Issue was that mouse pressed on the scrollbars of all virtualized controls
> cancelled the edit. That's inconsistent with other scroll triggers
> (mouseWheel, programmatic). Fixed by removing the cancel.
>
&
On Thu, 2 Dec 2021 00:18:37 GMT, Kevin Rushforth wrote:
>> Issue was that mouse pressed on the scrollbars of all virtualized controls
>> cancelled the edit. That's inconsistent with other scroll triggers
>> (mouseWheel, programmatic). Fixed by removing the cancel.
>>
>> Added tests that
On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote:
> This PR fixes an issue where the `DatePicker` is not committing his value
> when the focus is lost.
> As the ticket also mentions, this is a regression which last worked on JavaFX
> 8 and got broken by the refactoring:
>
The misbehaviour was that an edit handler received both a commit and cancel
event when cell commitEdit is called. That happened whenever a collaborator
reset the controls editing state (either directly or indirectly) while
processing the editCommit event. The reason was that the cell had not
On Mon, 29 Nov 2021 14:38:10 GMT, Michael Strauß wrote:
>> After (re)setting the number of elements, make sure to do at least some
>> estimation of the total size.
>> Added a testcase for this scenario.
>
> modules/javafx.controls/src/main/java/javafx/scene/control/skin/VirtualFlow.java
> line
On Wed, 24 Nov 2021 04:23:59 GMT, Michael Strauß wrote:
> This PR renames `TextBinding` to `MnemonicInfo` and adds the following text
> to its javadoc:
>
> /**
> 33 +* Provides information about mnemonics contained within a string.
looks good (modulo our disagreement on
Issue was that mouse pressed on the scrollbars of all virtualized controls
cancelled the edit. That's inconsistent with other scroll triggers (mouseWheel,
programmatic). Fixed by removing the cancel.
Added tests that failed/passed before/after the fix. Also added tests that
passed both
On Wed, 24 Nov 2021 09:09:53 GMT, Marius Hanl wrote:
> This PR fixes an issue where the `DatePicker` is not committing his value
> when the focus is lost.
> As the ticket also mentions, this is a regression which last worked on JavaFX
> 8 and got broken by the refactoring:
>
On Fri, 24 Sep 2021 16:01:38 GMT, Jeanette Winzenburg
wrote:
> Cleanup of Tree-/TableRowSkin to support switching skins
>
> The misbehavior/s
> - memory leaks due to manually registered listeners that were not removed
> - side-effects due to listeners still active on old
On Mon, 15 Nov 2021 14:34:04 GMT, Marius Hanl wrote:
> When a divider is moved via drag or code it will call **requestLayout()** for
> the **SplitPane**.
> While this is fine, it is also called when the
> **SplitPaneSkin#layoutChildren(..)** method is repositioning the divider.
>
> This makes
roperty changes of its control, throwing NPEs when not added to a
> VirtualFlow) which are not part of this issue but covered in
> [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last r
On Fri, 19 Nov 2021 09:24:42 GMT, Ajit Ghaisas wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> reverted fixedCellSize handling
>
> modules/javafx.controls/src/shims/
On Fri, 19 Nov 2021 09:45:06 GMT, Ajit Ghaisas wrote:
>> FYI: now the listener registration - including the incorrect code comment
>> (which is the same as in current master) - is back at the old location in
>> the re-inserted setupTreeTableViewListeners. So still need input whether
>> it's
On Mon, 1 Nov 2021 12:59:42 GMT, Marius Hanl wrote:
>> well .. that would be a merge conflict, had you updated the code comment in
>> your PR As noted in my comments to Ajit's review, the listener
>> registration is simply moved (including the code comment .. belatedly :)
>>
>> Not sure how
part of this issue but covered in
> [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last revision:
reverted fixedCellSize handling
-
Changes:
- all: https://git.openjdk.java.
On Wed, 10 Nov 2021 17:45:32 GMT, Michael Strauß wrote:
>
>
> @kleopatra Can you be a reviewer on this PR?
css is not my turf, sry
-
PR: https://git.openjdk.java.net/jfx/pull/475
On Sun, 31 Oct 2021 17:05:52 GMT, Michael Strauß wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> re-added forgotten code comments
>
> modules/javafx.controls/src/main/
On Sun, 31 Oct 2021 18:07:27 GMT, Marius Hanl wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> re-added forgotten code comments
>
> modules/javafx.controls/src/main/
part of this issue but covered in
> [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last revision:
removed unused code, fixed doc of test methods
-
Changes:
- all: ht
On Fri, 29 Oct 2021 13:58:35 GMT, Michael Strauß wrote:
>> This PR fixes an issue with mnemonic parsing by removing the restriction
>> that a mnemonic symbol must be a letter. Now, it can be any character except
>> whitespace.
>
> Michael Strauß has updated the pull request incrementally with
On Fri, 29 Oct 2021 23:14:07 GMT, Michael Strauß wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/skin/LabelSkinTest.java
>> line 2162:
>>
>>> 2160: label.autosize();
>>> 2161: skin.updateDisplayedText();
>>> 2162: assertEquals("foo _bar _qux",
On Tue, 5 Oct 2021 13:18:07 GMT, Jeanette Winzenburg
wrote:
> 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 to
On Tue, 26 Oct 2021 12:07:23 GMT, Ajit Ghaisas wrote:
>> Jeanette Winzenburg has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> re-added forgotten code comments
>
> modules/javafx.controls/src/main/
part of this issue but covered in
> [JDK-8274065](https://bugs.openjdk.java.net/browse/JDK-8274065)
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last revision:
re-added forgotten code comments
-
Changes:
- all: https://git.openjdk.java.
ixed 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
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);
>&g
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 unus
On Wed, 13 Oct 2021 21:25:43 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 unus
ixed 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:
fixed formatting as suggested in review
and removed unused (by this fix
On Thu, 7 Oct 2021 10:35:12 GMT, Marius Hanl wrote:
>
>
> And by the way, you know why there is a requestFocus() in List/TreeCell, but
> not in the other two cells? :)
plain oversight? or the wrong thing to do, anyway? or having weird side-effects
in tabular controls which were evaded by
On Wed, 6 Oct 2021 15:34:14 GMT, Jeanette Winzenburg
wrote:
>
> > Interesting, I just saw that it worked before because of the
> > TableCellBehavior (edit method). Does this mean this can be removed from
> > the behaviour in future?
>
> hmm .. the behavior ta
On Wed, 6 Oct 2021 15:15:16 GMT, Marius Hanl wrote:
>
>
> Interesting, I just saw that it worked before because of the
> TableCellBehavior (edit method). Does this mean this can be removed from the
> behaviour in future?
hmm .. the behavior talks directly to the control (not the cell) by
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.
On Thu, 30 Sep 2021 12:00:16 GMT, Jeanette Winzenburg
wrote:
> The misbehavior happens if (super) startEdit didn't succeed (==
> !cell.isEditing):
>
> - must not fire editStart event
> - must not update control's editing location
>
> fix is to back out of startEdit if su
), so it's
> ignore until that's fixed.
Jeanette Winzenburg has updated the pull request incrementally with one
additional commit since the last revision:
test cleanup, following review comments
-
Changes:
- all: https://git.openjdk.java.net/jfx/pull/636/files
- new: https
On Fri, 1 Oct 2021 13:11:21 GMT, Marius Hanl wrote:
>> The misbehavior happens if (super) startEdit didn't succeed (==
>> !cell.isEditing):
>>
>> - must not fire editStart event
>> - must not update control's editing location
>>
>> fix is to back out of startEdit if super.startEdit doesn't
On Fri, 1 Oct 2021 13:10:29 GMT, Marius Hanl wrote:
>> The misbehavior happens if (super) startEdit didn't succeed (==
>> !cell.isEditing):
>>
>> - must not fire editStart event
>> - must not update control's editing location
>>
>> fix is to back out of startEdit if super.startEdit doesn't
The misbehavior happens if (super) startEdit didn't succeed (==
!cell.isEditing):
- must not fire editStart event
- must not update control's editing location
fix is to back out of startEdit if super.startEdit doesn't switch the cell into
editing mode
Added tests that failed/passed
On Sun, 26 Sep 2021 12:05:11 GMT, Jeanette Winzenburg
wrote:
> the other way round: a cell that didn't switch into editing will nevertheless
> fire a editStart on its target
FYI: filed [JDK-8274433](https://bugs.openjdk.java.net/browse/JDK-8274433)
-
PR:
On Sun, 19 Sep 2021 11:24:43 GMT, Marius Hanl wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/cell/ChoiceBoxTreeCell.java
>> line 301:
>>
>>> 299: return;
>>> 300: }
>>> 301:
>>
>> (darn, can't add the important lines - which is backing out if
On Sun, 19 Sep 2021 11:52:55 GMT, Marius Hanl wrote:
>> This PR sets an unified logic to every **startEdit()** method of all Cell
>> implementations.
>> So startEdit() is always doing the same now:
>>
>> `super.startEdit();`
>> `if (!isEditing()) {
>> return;
>> }`
>>
>> This will prevent a
On Tue, 7 Sep 2021 14:53:50 GMT, Jeanette Winzenburg
wrote:
> this PR fixes the inconsistent event firing pattern in cell's xxEdit methods
> (please see the issue for more details):
>
> - fires event if column != null
> - accesses table state if table != null
>
> The fi
Cleanup of Tree-/TableRowSkin to support switching skins
The misbehavior/s
- memory leaks due to manually registered listeners that were not removed
- side-effects due to listeners still active on old skin (like NPEs)
Fix
- use skin api for all listener registration (for automatic removal in
Vote: YES
Zitat von Kevin Rushforth :
I hereby nominate Thiago Sayao [1] to OpenJFX Committer.
Thiago is an OpenJFX community member, who has contributed 15
commits [2] to OpenJFX.
Votes are due by September 27, 2021 at 15:00 UTC.
Only current OpenJFX Committers [3] are eligible to
On Thu, 22 Jul 2021 19:15:54 GMT, Marius Hanl wrote:
>>> > just checked my notes (there's a cell-editing branch in my fork where I'm
>>> > experimenting) - astonishingly the answer is no, could not see anything
>>> > :) And actually, seems like we don't even need to return immediately:
>>> >
On Thu, 9 Sep 2021 09:47:56 GMT, Michael Strauß wrote:
>
>
> > Just curious: with this in place, would it be possible to use for
> > supporting [JDK-8087926](https://bugs.openjdk.java.net/browse/JDK-8087926)
> > (it's a bit vague, though, at least for me)?
>
> Yes, `:focus-within` can be
On Fri, 20 Aug 2021 05:15:49 GMT, Michael Strauß wrote:
>> This PR adds the `Node.focusVisible` and `Node.focusWithin` properties, as
>> well as the corresponding `:focus-visible` and `:focus-within` CSS
>> pseudo-classes.
>
> Michael Strauß has updated the pull request incrementally with one
this PR fixes the inconsistent event firing pattern in cell's xxEdit methods
(please see the issue for more details):
- fires event if column != null
- accesses table state if table != null
The first requires a change in CellEditEvent which now allows null table in its
constructor.
Added
On Thu, 26 Aug 2021 14:09:58 GMT, Jeanette Winzenburg
wrote:
> The issue is unguarded access to tablePosition though it might be null (since
> [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610)
>
> The fix is to check against null in each accessor. Also req
to really cope with null
> TablePostion on the event.
>
> Added tests that failed/pass before/after the fix.
>
> Note that there was an old test (in Tree/TableColumnTest each), that failed
> after the fix because it expected the NPE. Fixed by removing the expected
> paramet
On Fri, 3 Sep 2021 15:00:32 GMT, Ajit Ghaisas wrote:
>> The issue is unguarded access to tablePosition though it might be null
>> (since [JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610)
>>
>> The fix is to check against null in each accessor. Also required to fix the
>> default
On Thu, 2 Sep 2021 12:45:02 GMT, Jeanette Winzenburg
wrote:
> minor skin cleanup issue: SeparatorSkin didn't remove the line it added to
> the control's children
>
> fix is to override dispose and include the removal
> for testing: removed the exclusion of SeparatorSkin from
minor skin cleanup issue: SeparatorSkin didn't remove the line it added to the
control's children
fix is to override dispose and include the removal
for testing: removed the exclusion of SeparatorSkin from memoryLeakTest - doing
so lets it fail/pass before/after this fix
-
Commit
On Fri, 27 Aug 2021 11:15:58 GMT, Jeanette Winzenburg
wrote:
> left-over issue from cleanup of Tree/ListViewSkin: direct children that have
> been added by the skin must be removed in dispose
>
> fixed by removing the flow (which allowed to revert the previous cleanup of
>
Hi Nir,
looks similar to
https://mail.openjdk.java.net/pipermail/openjfx-dev/2021-May/030563.html which
I'm seeing since May - don't know (and didn't dig ;) why or how to
solve, I simply ignore them.
-- Jeanette
Zitat von Nir Lisker :
Hi,
When running builds, gradle reports
Zitat von Kevin Rushforth :
Yes, it would be great to finally solve this one. It would need
someone who is willing and able to to drive it, though.
-- Kevin
Well, I think myself being both - with a little help of my friends ;)
-- Jeanette
On 8/4/2021 2:58 AM, Jeanette Winzenburg
left-over issue from cleanup of Tree/ListViewSkin: direct children that have
been added by the skin must be removed in dispose
fixed by removing the flow (which allowed to revert the previous cleanup of
event handlers/cellfactory)
added tests to verify
- constant child count after replacing
The issue is unguarded access to tablePosition though it might be null (since
[JDK-8120610](https://bugs.openjdk.java.net/browse/JDK-8120610)
The fix is to check against null in each accessor. Also required to fix the
default onEditCommit handlers in Tree/TableColumn to really cope with null
On 26-Aug-2021, at 5:33 PM, Jeanette Winzenburg
wrote:
.. general problem or just me? How to solve?
Thanks for any help,
Jeanette
.. general problem or just me? How to solve?
Thanks for any help,
Jeanette
On Sat, 14 Aug 2021 10:32:00 GMT, Jeanette Winzenburg
wrote:
> The issue was a glaring contract violation of TextAreaSkin which throws a
> UnsupportedOperationException. The fix was to remove the throwing and cleanup
> on dispose which implies
>
> in TextAreaBehavior:
> - r
On Tue, 17 Aug 2021 16:15:47 GMT, Marius Hanl wrote:
>> This PR sets an unified logic to every **startEdit()** method of all Cell
>> implementations.
>> So startEdit() is always doing the same now:
>>
>> `super.startEdit();`
>> `if (!isEditing()) {
>> return;
>> }`
>>
>> This will prevent a
On Mon, 16 Aug 2021 17:09:25 GMT, Marius Hanl wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/ListCellStartEditTest.java
>> line 75:
>>
>>> 73: this.listCell = listCell;
>>> 74: }
>>> 75:
>>
>> this hit me when trying separate out the (accidentally?)
The issue was a glaring contract violation of TextAreaSkin which throws a
UnsupportedOperationException. The fix was to remove the throwing and cleanup
on dispose which implies
in TextAreaBehavior:
- remove the listener to focusProperty in dispose
in TextAreaSkin:
- register all listeners to
On Thu, 29 Jul 2021 14:11:15 GMT, Jeanette Winzenburg
wrote:
> The NPE was an indirect effect:
>
> - the bug on part of the cell was an incorrect (== missing) edit location in
> cellEditEvent - that's fixed in this PR
> - a related bug is on part of the implementation o
On Wed, 11 Aug 2021 08:38:45 GMT, Ajit Ghaisas wrote:
>
>
> The fix looks good to me.
thanks :)
-
PR: https://git.openjdk.java.net/jfx/pull/592
1 - 100 of 633 matches
Mail list logo
