Yes, please!
Julez On Tue, Feb 2, 2021, 2:37 PM , <naast...@gmail.com> 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 "<? extends > 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 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 could just ask people on Reddit to translate > controls.properties (it's really short) into their > native language and commit it yourself. > > Thanks for reading this. > > Best regards > Mike > >
