Make javafx.controls open and community-driven

[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 , <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
>>
>>