Re: Make javafx.controls open and community-driven
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 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 are abandoned or badly maintained (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, like ControlsFX. Look how small the numbers of real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX or have plans to use it in any near future. Eclipse sticks with SWT, NetBeans uses FlatLaf ( https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of resources into JetPack Compose. They even implemented interop layer for Swing apps ( https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ ). OpenJFX team is understaffed while modern desktop and mobile applications require more components that JavaFX could provide (and support) at the moment. javafx.controls are outdated and Modena theme doesn't look pleasing anymore. But that's not the worst part about it. The worst part is that it's almost impossible to extend existing components. I do understand that current resources and maintainers time are very limited and maintaining graphics layer should be top priority. The only thing I ask is to REMOVE BARRIERS that stop those who want to improve standard controls. Make javafx.controls fully open. Allow community to fix things that you don't have time to fix. 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK maintainers. But OpenJFX is not a part of OpenJDK, not anymore. No other UI library imposes strict limitations like these. Check Electron, Avalonia, WXwidgets, even god-damned proprietary Qt. While it may be the case for low-level stuff like javafx.graphics it's absolutely unacceptable for controls. You're stopping a lot of people from commenting existing bugs and sharing their workarounds and any feedback they could provide. Moreover you require signing OCA from everyone who want to commit into controls even if it's a slightest improvement. 2. Controls implementation is hidden for NO GOOD REASON. Almost everything in skins is private and things like *Behavior are module-private. Hello, fellow users! Wanna DatePicker w/o text field or TreeCell w/o disclosure node? Sorry, you can't w/o re-implementing everything from scratch. This is effectively stops everyone who want to improve current skin for it's own project or create a library that extends current controls. https://github.com/sshahine/JFoenix/issues/955 https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above That's why JS is so popular. No self imposed limitations! Everything is customizable, manipulate the DOM in any way you want. 3. javafx.controls i18n support is very limited ( https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ resources). You've put a lot or resources in thing like RTL implementation, but who cares if there's literally no API to customize standard controls. Back to #2, it would be possible if you'd opened skins for customization or/and reflection. Summary: - Move javafx.controls support to the Github (not to javafxports, it's outdated and barely maintained). Mark issues: "good first issue", "help needed" etc. Everyone do this, because it helps to encourage new devs to participate into development. This is exactly how social coding works. - Allow community to extend and improve controls in any way they want. Export "com.sun.javafx.scene.control" (esp "com.sun.javafx.scene.control.behavior.*") and make everything "" inside skins protected, not private. I beg you to hear me. Controls are just controls, it's not a platform thing, it's not something sacred you should keep in private. You can't possibly foreknow all possible uses cases. By stopping to extend them you just lose your users and that's it. They simply go away and use more extensible and feature-rich alternative. Ironically, even Swing beats JavaFX in that case. We need more libraries like JFoenix and ControlsFX. Without that you can't compete with either Flutter or Compose in near future. You literally doom JavaFX to stay a bunch of legacy controls no one really like or want to use. Ideally javafx.controls should not rely on private javafx.graphics or javafx.base API at all. - Be open. Stop hiding in mailing lists. There's no corporation behind JavaFX, it won't survive without community. There's https://www.reddit.com/r/JavaFX. Share your plans, make regular announcements, discuss what need to be improved. Guide community efforts! - Invest some time into i18n support. There's no way to
Re: Make javafx.controls open and community-driven
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 dead" on Reddit or > similar resources. Look how many community libraries are abandoned or > badly maintained > (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, > like ControlsFX. Look how small the numbers of > real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX > or have plans to use it in any near future. > Eclipse sticks with SWT, NetBeans uses FlatLaf ( > https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of > resources into JetPack Compose. They even implemented interop layer for > Swing apps > ( > https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/ > ). > > OpenJFX team is understaffed while modern desktop and mobile applications > require more components that JavaFX could > provide (and support) at the moment. javafx.controls are outdated and > Modena theme doesn't look pleasing anymore. But > that's not the worst part about it. The worst part is that it's almost > impossible to extend existing components. I do > understand that current resources and maintainers time are very limited > and maintaining graphics layer should be top > priority. The only thing I ask is to REMOVE BARRIERS that stop those who > want to improve standard controls. Make > javafx.controls fully open. Allow community to fix things that you don't > have time to fix. > > 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK > maintainers. But OpenJFX is not a part of > OpenJDK, not anymore. No other UI library imposes strict limitations like > these. Check Electron, Avalonia, WXwidgets, > even god-damned proprietary Qt. While it may be the case for low-level > stuff like javafx.graphics it's absolutely > unacceptable for controls. You're stopping a lot of people from commenting > existing bugs and sharing their workarounds > and any feedback they could provide. Moreover you require signing OCA from > everyone who want to commit into controls > even if it's a slightest improvement. > > 2. Controls implementation is hidden for NO GOOD REASON. Almost everything > in skins is private and things like *Behavior > are module-private. Hello, fellow users! Wanna DatePicker w/o text field > or TreeCell w/o disclosure node? Sorry, you > can't w/o re-implementing everything from scratch. This is effectively > stops everyone who want to improve current skin > for it's own project or create a library that extends current controls. > > https://github.com/sshahine/JFoenix/issues/955 > > https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above > > That's why JS is so popular. No self imposed limitations! Everything is > customizable, manipulate the DOM in any way you > want. > > 3. javafx.controls i18n support is very limited > ( > https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ > > > resources). You've put a lot or resources in thing like RTL > implementation, but who cares if there's literally no API to > customize standard controls. Back to #2, it would be possible if you'd > opened skins for customization or/and reflection. > > Summary: > > - Move javafx.controls support to the Github (not to javafxports, it's > outdated and barely maintained). Mark issues: > "good first issue", "help needed" etc. Everyone do this, because it helps > to encourage new devs to participate into > development. This is exactly how social coding works. > - Allow community to extend and improve controls in any way they want. > Export "com.sun.javafx.scene.control" (esp > "com.sun.javafx.scene.control.behavior.*") and make everything " Node>" inside skins protected, not private. > I beg you to hear me. Controls are just controls, it's not a platform > thing, it's not something sacred you should keep > in private. You can't possibly foreknow all possible uses cases. By > stopping to extend them you just lose your users and > that's it. They simply go away and use more extensible and feature-rich > alternative. Ironically, even Swing beats JavaFX > in that case. We need more libraries like JFoenix and ControlsFX. Without > that you can't compete with either Flutter or > Compose in near future. You literally doom JavaFX to stay a bunch of > legacy controls no one really like or want to use. > Ideally javafx.controls should not rely on private javafx.graphics or > javafx.base API at all. > - Be open. Stop hiding in mailing lists. There's no corporation behind > JavaFX, it won't survive without community. > There's https://www.reddit.com/r/JavaFX. Share your plans, make regular > announcements, discuss what need to be improved. > Guide community efforts! > - Invest
Make javafx.controls open and community-driven
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 are abandoned or badly maintained (https://github.com/mhrimaz/AwesomeJavaFX), including most popular ones, like ControlsFX. Look how small the numbers of real-world JavaFX apps. Also notice that no major Java apps adopted JavaFX or have plans to use it in any near future. Eclipse sticks with SWT, NetBeans uses FlatLaf (https://github.com/JFormDesigner/FlatLaf) and JetBrains puts lots of resources into JetPack Compose. They even implemented interop layer for Swing apps (https://blog.jetbrains.com/cross-post/jetpack-compose-for-desktop-milestone-2-released/). OpenJFX team is understaffed while modern desktop and mobile applications require more components that JavaFX could provide (and support) at the moment. javafx.controls are outdated and Modena theme doesn't look pleasing anymore. But that's not the worst part about it. The worst part is that it's almost impossible to extend existing components. I do understand that current resources and maintainers time are very limited and maintaining graphics layer should be top priority. The only thing I ask is to REMOVE BARRIERS that stop those who want to improve standard controls. Make javafx.controls fully open. Allow community to fix things that you don't have time to fix. 1. The first obstacle is JBS. It's read-only for everyone, but OpenJDK maintainers. But OpenJFX is not a part of OpenJDK, not anymore. No other UI library imposes strict limitations like these. Check Electron, Avalonia, WXwidgets, even god-damned proprietary Qt. While it may be the case for low-level stuff like javafx.graphics it's absolutely unacceptable for controls. You're stopping a lot of people from commenting existing bugs and sharing their workarounds and any feedback they could provide. Moreover you require signing OCA from everyone who want to commit into controls even if it's a slightest improvement. 2. Controls implementation is hidden for NO GOOD REASON. Almost everything in skins is private and things like *Behavior are module-private. Hello, fellow users! Wanna DatePicker w/o text field or TreeCell w/o disclosure node? Sorry, you can't w/o re-implementing everything from scratch. This is effectively stops everyone who want to improve current skin for it's own project or create a library that extends current controls. https://github.com/sshahine/JFoenix/issues/955 https://github.com/controlsfx/controlsfx/wiki/Using-ControlsFX-with-JDK-9-and-above That's why JS is so popular. No self imposed limitations! Everything is customizable, manipulate the DOM in any way you want. 3. javafx.controls i18n support is very limited (https://github.com/openjdk/jfx/tree/jfx16/modules/javafx.controls/src/main/resources/com/sun/javafx/scene/control/skin/ resources). You've put a lot or resources in thing like RTL implementation, but who cares if there's literally no API to customize standard controls. Back to #2, it would be possible if you'd opened skins for customization or/and reflection. Summary: - Move javafx.controls support to the Github (not to javafxports, it's outdated and barely maintained). Mark issues: "good first issue", "help needed" etc. Everyone do this, because it helps to encourage new devs to participate into development. This is exactly how social coding works. - Allow community to extend and improve controls in any way they want. Export "com.sun.javafx.scene.control" (esp "com.sun.javafx.scene.control.behavior.*") and make everything "" inside skins protected, not private. I beg you to hear me. Controls are just controls, it's not a platform thing, it's not something sacred you should keep in private. You can't possibly foreknow all possible uses cases. By stopping to extend them you just lose your users and that's it. They simply go away and use more extensible and feature-rich alternative. Ironically, even Swing beats JavaFX in that case. We need more libraries like JFoenix and ControlsFX. Without that you can't compete with either Flutter or Compose in near future. You literally doom JavaFX to stay a bunch of legacy controls no one really like or want to use. Ideally javafx.controls should not rely on private javafx.graphics or javafx.base API at all. - Be open. Stop hiding in mailing lists. There's no corporation behind JavaFX, it won't survive without community. There's https://www.reddit.com/r/JavaFX. Share your plans, make regular announcements, discuss what need to be improved. Guide community efforts! - Invest some time into i18n support. There's no way to localize controls w/o dirty hack (https://pastebin.com/RgadNwZd). If you'd removed JBS/OCA barrier for javafx.controls more people could help you with that. Even w/o that you
Integrated: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows
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. The same is not present in `WorkQueueGeneric` and needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. This pull request has now been integrated. Changeset: e481f8c7 Author:Arun Joseph URL: https://git.openjdk.java.net/jfx/commit/e481f8c7 Stats: 212 lines in 3 files changed: 13 ins; 199 del; 0 mod 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260475: Deprecate for removal protected access members in DateTimeStringConverter
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 or method, similar to what we recently did for [JDK-8252387](https://bugs.openjdk.java.net/browse/JDK-8252387)? - PR: https://git.openjdk.java.net/jfx/pull/390
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6]
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 `git rebase master`, since the former doesn't require force-pushing. > > I do see that there are no changes from last time, which is good, so it will > be fine for this time. > > When ready, you can add the new test by pushing a new commit. @kevinrushforth I was not aware of that, thank you for letting me know! I wrote a new test for vertical axes and discovered that there were more issues with axis layout calculations, which I also addressed. I also found out that the layout tests sometimes fail without a short pause using `Util.sleep()`. I don't really like having to add sleeps, but I did find that it got rid of any test flakiness. - PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v6]
> 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 layout horizontally. > This fixes the fact that the axis labels are truncated and also ensures that > the chart does not leave unused space from the layout calculations. > `CategoryAxis` is already setting the `categorySpacing` property when > `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request incrementally with two additional commits since the last revision: - Add tests for vertical axis as well - Improve layout calculations for rotated text - Changes: - all: https://git.openjdk.java.net/jfx/pull/342/files - new: https://git.openjdk.java.net/jfx/pull/342/files/dff9ee17..d5a3fae9 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=342=05 - incr: https://webrevs.openjdk.java.net/?repo=jfx=342=04-05 Stats: 134 lines in 3 files changed: 120 ins; 1 del; 13 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]
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 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 `git rebase master`, since the former doesn't require force-pushing. I do see that there are no changes from last time, which is good, so it will be fine for this time. When ready, you can add the new test by pushing a new commit. - PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]
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 >> labels that are rotated even when they don't need to be. > > @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 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 `git rebase master`, since the former doesn't require force-pushing. - PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8255572: Axis does not compute preferred height properly when autoRanging is off [v5]
> 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 layout horizontally. > This fixes the fact that the axis labels are truncated and also ensures that > the chart does not leave unused space from the layout calculations. > `CategoryAxis` is already setting the `categorySpacing` property when > `autoRanging` is off, so this seems to be an appropriate fix. Jonathan Vusich has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Remove unused import - Unrotate labels if there is enough space for them - Added copyright header - Added fix and test - Changes: https://git.openjdk.java.net/jfx/pull/342/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=342=04 Stats: 126 lines in 2 files changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/342.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/342/head:pull/342 PR: https://git.openjdk.java.net/jfx/pull/342
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
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 early. The same is not present in `WorkQueueGeneric` and needs to be >> added. >> >> Also removing `WorkQueueWin` as it's removed for WebKit as well. > > Arun Joseph has updated the pull request incrementally with one additional > commit since the last revision: > > Update comment Looks good. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
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:
>
>> 83: // so far.
>> 84: const Seconds slopAdjustment { 20_ms };
>> 85: if (delay)
>
> Since `delay` is an object of type `Seconds`, should this be `if
> (delay.milliseconds())`? Otherwise, won't it just check whether the object is
> non-null?
In
[Seconds.h](https://github.com/openjdk/jfx/blob/master/modules/javafx.web/src/main/native/Source/WTF/wtf/Seconds.h),
there's an `operator bool()` which checks the m_value.
-
PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
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 early. The same is not present in `WorkQueueGeneric` and needs to be
>> added.
>>
>> Also removing `WorkQueueWin` as it's removed for WebKit as well.
>
> 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:
> 83: // so far.
> 84: const Seconds slopAdjustment { 20_ms };
> 85: if (delay)
Since `delay` is an object of type `Seconds`, should this be `if
(delay.milliseconds())`? Otherwise, won't it just check whether the object is
non-null?
-
PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows [v2]
> 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 needs to be added. > > Also removing `WorkQueueWin` as it's removed for WebKit as well. Arun Joseph has updated the pull request incrementally with one additional commit since the last revision: Update comment - Changes: - all: https://git.openjdk.java.net/jfx/pull/391/files - new: https://git.openjdk.java.net/jfx/pull/391/files/739f3207..ea61414f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=391=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=391=00-01 Stats: 10 lines in 1 file changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/391.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/391/head:pull/391 PR: https://git.openjdk.java.net/jfx/pull/391
Re: RFR: 8260163: IrresponsiveScriptTest.testInfiniteLoopInScript unit test fails on Windows
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. The same is not present in `WorkQueueGeneric` and needs to be added.
>
> Also removing `WorkQueueWin` as it's removed for WebKit as well.
The fix and the test look good with one question and one doc comment.
modules/javafx.web/src/main/native/Source/WTF/wtf/generic/WorkQueueGeneric.cpp
line 78:
> 76: // Adding the slop adjustment from wtf/win/WorkQueueWin.cpp
> 77: const Seconds slopAdjustment { 20_ms };
> 78: delay += slopAdjustment;
Can you replace the above comment with the actual comment from the
(now-deleted) `WorkQueueWin.cpp` file? Also, I see that the original fix only
added the `slopAdjustment` if `delay` was non-zero. Should that be preserved?
-
PR: https://git.openjdk.java.net/jfx/pull/391
Re: [jfx16] RFR: 8252389: Fix mistakes in FX API docs [v3]
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 comments Marked as reviewed by kcr (Lead). - PR: https://git.openjdk.java.net/jfx/pull/380
Integrated: 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys
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 usages where the keyboard input might not be echoed. It would also > allow an application to do spell checking / auto-correction that might > ordinarily be skipped when typing all upper-case letters. > > We need an equivalent JavaFX API to the existing AWT > `java.awt.ToolKit::getLockingKeyState` method. A natural place to put this in > JavaFX is in the `javafx.application.Platform` class, so we propose to create > a new `Platform::isKeyLocked` method, which will take a `KeyCode` -- either > `CAPS` or `NUM_LOCK` -- and return an `Optional` indicating whether > or not that key is in the locked or "on" state. If we can't read the key > state on a particular platform, we will return `Optional.empty()`, rather > than throwing a runtime exception as AWT does. > > I have provided both an automated Robot test and a manual test. The latter is > needed primarily because we can't set the CAPS lock on Mac using Robot, but > also because we want way to test the case where the user has enabled CAPS > lock before the program starts. This pull request has now been integrated. Changeset: 217a8cba Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx/commit/217a8cba Stats: 446 lines in 15 files changed: 445 ins; 0 del; 1 mod 8259680: Need API to query states of CAPS LOCK and NUM LOCK keys Reviewed-by: arapte, pbansal - PR: https://git.openjdk.java.net/jfx/pull/385
