Hi Mike, First of all, I would have you consider revisiting your medical observation on the state of JavaFX. If you've read the almost-weekly recurrent threads of "should I use Swing or JavaFX" in r/Java, you'd realize that reports of JavaFX's death are greatly exaggerated. But yes, it is very understaffed. Other than that, there is a discussion list, openjfx-disc...@openjdk.java.net, where you can bring up general community and social media related topics and continue that branch of the discussion there.
1. I also advocated for having JBS more open in the past. I was told that Oracle tried opening JBS for everyone, but it was a big mess. I remember Alan Bateman saying a few years ago in an Ask The Architect session, when he was asked about this, that more than half of the bugs submitted are about OpenGL in Minecraft. These are the things you don't see from the outside. Another thing you need to consider is that we don't want to split the discussion of an issue between JBS and the mailing list. While I agree it's more comfortable to just be able to add a comment in the issue you are already reading, you can just write an email here, like you just did, with the extra info. I'm willing to spend the 30 seconds (most of which are spent on JBS loading :) ) of linking the discussion thread to the JBS issue myself. No one is being stopped from sharing their findings, this is the place to do it. As for the OCA, it is a license requirement for all of OpenJDK. The developers here have nothing to do with it. I suspect you will have to take it up with the legal department of Oracle. Good luck :) 2. There is a very good reason for hiding implementation. When you make something into a public API, you're making a long term commitment to its existence and functionality. This makes it very difficult to change it without breaking any existing behavior. Making everything public API is one of the worst decisions in terms of library design that wants to keep a contract with its users. There needs to be a way to allow controls extensions, I agree, but through an API that was designed for it. JS libraries break things all the time, which means that whenever you update a dependency you might need to rewrite some part of your code. That's the other side of the coin. The middleground is far from trivial. As for your points: - JavaFX is already on GitHub, it was one of the first (if not the first) OpenJDK project to transition. The javafxports repo was before Skara happened, and it has been defunct for a while now. We are on github.com/openjdk/jfx. - The mailing list is open, not hidden [1]. Social media is not a place to make formal announcements. The correct usage is to link announcements and such there (as done with all other OpenJDK projects and r/Java, for example). Since every reply here has agreed that it should be easier to customize controls, and there are many able bodies there, it seems like a discussion should start on a design plan (which is not "make everything public/protected). I would suggest first to break the general statement about controls into smaller chunks, like i18n, skins, css, behavior, extending an existing control vs creating a new one etc. Then look at existing issues for each, there have been many discussions on them in the past and this will give a good starting point. [1] http://mail.openjdk.java.net/pipermail/openjfx-dev/ Best, Nir On Tue, Feb 2, 2021 at 8:37 AM <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 > >
