Re: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse)

2022-08-30 Thread Andy Goryachev
On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are > configured to use JUnit5. you are right, sorry, I was talking about .project file. we can do it as part of JDK-8221708 - the main issue (and reluctance to mess with

Re: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse)

2022-08-30 Thread Nir Lisker
On Tue, 30 Aug 2022 19:09:40 GMT, Andy Goryachev wrote: > I wouldn't do it - it is convenient for git operations via context menu and > also gives access to other non-java parts (doc-files for instance). > > But the main issue is that it is has a > org.eclipse.buildship.core.gradleprojectnatur

Integrated: 8292678 Openjfx: all projects to use JUnit5 (Eclipse)

2022-08-30 Thread Andy Goryachev
On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are > configured to use JUnit5. This pull request has now been integrated. Changeset: eb8f2fe3 Author:Andy Goryachev Committer: Nir Lisker URL: https://git.op

Re: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse)

2022-08-30 Thread Andy Goryachev
On Tue, 30 Aug 2022 19:04:26 GMT, Nir Lisker wrote: > Please submit an issue for removing the root project's classpath file. I wouldn't do it - it is convenient for git operations via context menu and also gives access to other non-java parts (doc-files for instance). But the main issue is tha

Re: RFR: 8292678 Openjfx: all projects to use JUnit5 (Eclipse)

2022-08-30 Thread Nir Lisker
On Tue, 23 Aug 2022 18:38:48 GMT, Andy Goryachev wrote: > This change affects eclipse projects only - all eclipse projects are > configured to use JUnit5. Marked as reviewed by nlisker (Reviewer). Please submit an issue for removing the root project's classpath file. The 2 future changes to t

Re: RFR: 8217853: Cleanup in the D3D native pipeline [v5]

2022-08-30 Thread Nir Lisker
On Fri, 26 Aug 2022 17:34:41 GMT, Ambarish Rapte wrote: >> What do you mean by "revert the type function parameter here"? Doesn't the >> type parameter match after a change to the gradle file? > >> What do you mean by "revert the type function parameter here"? > > `VsOutput main(VsInput vsInput

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v3]

2022-08-30 Thread Andy Goryachev
On Tue, 30 Aug 2022 11:21:26 GMT, Jose Pereda wrote: >> The corner region is currently laid out with this assumption: >> >> // position the top-right rectangle (which sits above the scrollbar) >> >> However, the vertical scrollbar is not always visible. Therefore, when that >> is the c

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v3]

2022-08-30 Thread Andy Goryachev
On Tue, 30 Aug 2022 09:06:36 GMT, Jose Pereda wrote: >> modules/javafx.controls/src/main/java/javafx/scene/control/skin/TableColumnHeader.java >> line 381: >> >>> 379: } >>> 380: >>> 381: double cornerRegionPadding = tableHeaderRow == null ? 0d : >>> tableHeaderRow.cornerPaddi

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v3]

2022-08-30 Thread Jose Pereda
On Tue, 30 Aug 2022 10:44:39 GMT, Marius Hanl wrote: >> There are no exceptions expected to happen in these new tests and I don't >> see that we use try-finally with `StageLoader` by default, is this change >> really required? > > What we usually do is to add a global variable like this: > `pri

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v3]

2022-08-30 Thread Jose Pereda
> The corner region is currently laid out with this assumption: > > // position the top-right rectangle (which sits above the scrollbar) > > However, the vertical scrollbar is not always visible. Therefore, when that > is the case, the corner region is laid out on top of the table column

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v2]

2022-08-30 Thread Marius Hanl
On Tue, 30 Aug 2022 09:32:39 GMT, Jose Pereda wrote: >> modules/javafx.controls/src/test/java/test/javafx/scene/control/TableViewTest.java >> line 5883: >> >>> 5881: assertTrue(thumbMaxX < cornerMinX); >>> 5882: >>> 5883: sl.dispose(); >> >> may be in try/finally to dispose of

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy. [v2]

2022-08-30 Thread Jose Pereda
> The corner region is currently laid out with this assumption: > > // position the top-right rectangle (which sits above the scrollbar) > > However, the vertical scrollbar is not always visible. Therefore, when that > is the case, the corner region is laid out on top of the table column

Integrated: 8290841: Notify menu event after a long press gesture on Android is not dispatched

2022-08-30 Thread Jose Pereda
On Thu, 21 Jul 2022 23:03:31 GMT, Jose Pereda wrote: > This PR allows dispatching a menu event on Android to trigger a > ContextMenuEvent. > > It is somehow a follow-up of > [JDK-8245575](https://bugs.openjdk.java.net/browse/JDK-8245575), where the > same was added for iOS. > > While no tes

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy.

2022-08-30 Thread Jose Pereda
On Mon, 29 Aug 2022 22:40:15 GMT, Andy Goryachev wrote: >> The corner region is currently laid out with this assumption: >> >> // position the top-right rectangle (which sits above the scrollbar) >> >> However, the vertical scrollbar is not always visible. Therefore, when that >> is th

Re: RFR: 8087673: [TableView] TableView and TreeTableView menu button overlaps columns when using a constrained resize policy.

2022-08-30 Thread Jose Pereda
On Mon, 29 Aug 2022 22:29:22 GMT, Andy Goryachev wrote: >> The corner region is currently laid out with this assumption: >> >> // position the top-right rectangle (which sits above the scrollbar) >> >> However, the vertical scrollbar is not always visible. Therefore, when that >> is th