Re: Make javafx.controls open and community-driven

2021-02-01 Thread Tom Eugelink
I have to agree. All the protection measures, although well intended originally, are not helping. On 2-2-2021 08:02, Julian Jupiter wrote: Yes, please! Julez On Tue, Feb 2, 2021, 2:37 PM , wrote: Hello. JavaFX is a great toolkit, which personally I like a lot, but it's slowly dying

Re: Make javafx.controls open and community-driven

2021-02-01 Thread Julian Jupiter
Yes, please! Julez On Tue, Feb 2, 2021, 2:37 PM , wrote: > Hello. > > JavaFX is a great toolkit, which personally I like a lot, but it's slowly > dying for the past 5 years. You can barely > argue with that. Most of the devs still prefer Swing. Have a look how many > topics like "JavaFX is

Make javafx.controls open and community-driven

2021-02-01 Thread naastonn
Hello. JavaFX is a great toolkit, which personally I like a lot, but it's slowly dying for the past 5 years. You can barely argue with that. Most of the devs still prefer Swing. Have a look how many topics like "JavaFX is dead" on Reddit or similar resources. Look how many community libraries

Integrated: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows

2021-02-01 Thread Arun Joseph
On Mon, 1 Feb 2021 03:31:10 GMT, Arun Joseph wrote: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 > onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms > `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few > ms early.

Re: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter

2021-02-01 Thread Kevin Rushforth
On Sat, 30 Jan 2021 20:56:07 GMT, Nir Lisker wrote: > Deprecating protected members in DateTimeStringConverter. Internal > implementation should not be exposed (similar to `NumberStringConverter` and > others). Can you also add a javadoc comment block with an `@deprecated tag` to each field

Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6]

2021-02-01 Thread Jonathan Vusich
On Mon, 1 Feb 2021 21:37:44 GMT, Kevin Rushforth wrote: >> @JonathanVusich Once a review is in progress, please don't force-push your >> branch without a compelling reason, since that makes it harder to do >> incremental reviews. In the future, we recommend `git merge master` rather >> than

Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6]

2021-02-01 Thread Jonathan Vusich
> As noted in the corresponding JBS issue, `Axis` does not properly compute its > preferred height when `autoRanging` is turned off. The simplest fix seems to > be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees > if there is not enough room for the category labels to

Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]

2021-02-01 Thread Kevin Rushforth
On Mon, 1 Feb 2021 21:28:58 GMT, Kevin Rushforth wrote: >> @kevinrushforth Thank you for catching that. Do you think it would be >> acceptable to simply rotate the labels back to zero if the user expands the >> window? > > @JonathanVusich Once a review is in progress, please don't force-push

Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]

2021-02-01 Thread Kevin Rushforth
On Wed, 25 Nov 2020 15:56:05 GMT, Jonathan Vusich wrote: >> While this does fix the specific problem, it introduces a new one. If the >> labels are initially too big, but after resizing the window would now fit, >> it does not recompute the orientation. This means that you are left with >>

Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]

2021-02-01 Thread Jonathan Vusich
> As noted in the corresponding JBS issue, `Axis` does not properly compute its > preferred height when `autoRanging` is turned off. The simplest fix seems to > be changing `CategoryAxis` so that `tickLabelRotation` is set to 90 degrees > if there is not enough room for the category labels to

Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]

2021-02-01 Thread Kevin Rushforth
On Mon, 1 Feb 2021 16:52:10 GMT, Arun Joseph wrote: >> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 >> onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms >> `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a >> few ms

Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]

2021-02-01 Thread Arun Joseph
On Mon, 1 Feb 2021 16:55:50 GMT, Kevin Rushforth wrote: >> Arun Joseph has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Update comment > > modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp > line 85: > >>

Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]

2021-02-01 Thread Kevin Rushforth
On Mon, 1 Feb 2021 16:52:10 GMT, Arun Joseph wrote: >> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 >> onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms >> `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a >> few ms

Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]

2021-02-01 Thread Arun Joseph
> Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 > onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms > `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few > ms early. The same is not present in `WorkQueueGeneric` and

Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows

2021-02-01 Thread Kevin Rushforth
On Mon, 1 Feb 2021 03:31:10 GMT, Arun Joseph wrote: > Windows uses `WorkQueueGeneric` instead of `WorkQueueWin` from WebKit 610.2 > onwards. In `WorkQueueWin`, `WorkQueue::dispatchAfter()` had a 20 ms > `slopAdjustment` as the timer (called from `::SetTimer`) sometimes fire a few > ms early.

Re: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3]

2021-02-01 Thread Kevin Rushforth
On Sat, 30 Jan 2021 20:21:59 GMT, Nir Lisker wrote: >> The usual doc fixes (for OpenJFX 16). >> >> Can wait until RDP2 to see if something else comes up. > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Addressed review

Integrated: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys

2021-02-01 Thread Kevin Rushforth
On Sat, 23 Jan 2021 15:40:04 GMT, Kevin Rushforth wrote: > The JavaFX API does not provide a way to get the state of CAPS LOCK or NUM > LOCK on the keyboard. Being able to read the lock state would allow an > application to inform the user that caps lock was enabled for passwords or > other