Make javafx.controls open and community-driven

[Julian Jupiter]

Yes, please!


Julez

On Tue, Feb 2, 2021, 2:37 PM , <naastonn at 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
>
>