Hi, Interesting remarks.
> Hello, > > >> A 3rd party control, RichTextFX already exists -- what is this new > proposal adding that RichTextFX does not have? > > It uses the standard JavaFX VirtualFlow API and and does not need to work > with reactive streams. RichtextFX depends on several long unmaintained > libs: ReactFX (last commit 8 years ago), WellBehavedFX (last commit 6 years > ago), UndoFX (last commit 3 years ago). To say it's actively maintained is > a big exaggeration. > What do you think about our Rich Text Area project? https://github.com/gluonhq/rich-text-area I hear your concerns about depending on unmaintained libs, and it is one of my own primary filter criteria to either use or not use software >> What (if anything) is stopping a 3rd party from building a RichTextArea > themselves? > > - The lack of a standard API. The Behavior API has been discussed for > ages, but is still not implemented. Moreover, WellBehavedFX is literally a > rejected JEP/CSR implementation. > I agree a standard behavior API would be helpful, but I don't think it is needed for a third party control. I rather hope to see more third party controls being developed using different approaches, so that the community in general gets more experience with the different approaches, as that would give useful feedback on an approach to standardize it in OpenJFX. You know how it goes with projects in OpenJDK: once something is in, it has to be maintained and supported for a very long time and it is really hard to change it. > - The closedness of JavaFX in general. All internals are explicitly > private and final. A few simple examples. The date picker popup uses a > private API to calculate its width based on text size, but you're forbidden > to do the same thing. All i18n resources are not exported, you're forbidden > to use them to create a context menu. You're not encouraging 3rd party > libs, you're going in the opposite direction (for the sake of stability of > course). > Valid point. And it should be addressed. I wasn't part of the discussions where the decision was to close as much as possible, but I believe the idea was to close almost everything, and then to open API's when needed, after it was clear that opening the API would benefit the ecosystem without giving up stability. This happened a number of times in the past years, but I agree there is still much room for improvements. > - The JavaFX community is very small. The "tens of thousands of > developers" you talk about don't exist. Even famous projects are poorly > maintained or not maintained at all, including ControlsFX and ScenicView. > You have fewer features -> you have fewer users/market share -> you have > less promotion -> you have fewer committers -> you have fewer features. > It's that simple. > I think this is partly true, but it's more nuanced I believe. I am aware of a number of real large JavaFX projects, with many developers working on them. Most of these large projects are developed after closed walls, with lots of duplicated code that could go in a library. For the ecosystem as a whole, that's not good. It would be much better if we were in a situation where individual developers or companies would create and maintain libraries that would then be used in those big projects. For non-technical reasons, this is unfortunately not the case. > - There's literally no docs about creating new controls. Even Skin API is > badly documented. You can only learn from existing control libs. > This is a very valid concern. And I believe it is more important for us (openjfx-dev) to fix this, rather than do everything ourselves in the OpenJFX core. We need to encourage developers to create new controls, and provide more documentation, tutorials etc,... In the early days of JavaFX, there was a big team (it would now be called devrel I guess) that was working on this, helping developers and the ecosystem, but we know what happened next. That gap is not yet filled, and this is the price we are still paying for it. > This particular feature would be a HUGE step forward. I'm really glad to > see it. Hopefully it won't get buried under a bunch of pointless abstract > discussions like the CSS theme CSR. Just get some feedback and implement it > the way you want. It's a million times better than doing nothing. > Well, it's not that we're doing nothing. We are doing a number of things: 1. inside openjfx: keep it working. This should not be underestimated. With the fast and not always logical changes in platforms/OS code, there is lots of code under the hood that needs to be maintained and improved. A number of people on this list are extremely active on this, and spending lots of time on it. Unfortunately, this doesn't make headlines as the result of the hard work is often that "existing things keep working". Apart from keeping it working, I feel we are moving forward and making gradual progress. Over the past year, I saw more people contributing to OpenJFX and to this list, resulting in improvements in specific directions, and I am optimistic about that evolution. 2. outside openjfx: as I said, with Gluon we created this RTA ( https://github.com/gluonhq/rich-text-area). Because people wanted it, and because it would be good to experiment with it, without jeopardizing the OpenJFX stability. As for the pointless abstract discussions: we are somehow linked to the OpenJDK umbrella, where quality is valued much higher than adding hip features, and we try to stick to that principle as well (granted, I wouldn't call things like "tray support" a hip feature, so we are definitely not yet where we need to be). As a consequence, we do have lots of discussions before something gets in. For projects that deliver the foundations to an ecosystem, it is often better to not do something than to do it wrong. I know this is often unpopular, but being on the first row to fix things that were wrong from the beginning, I learned the hard way that this statement makes sense. That is not to say that we should not do anything. On the contrary, I'd love it if we could do more. But in the right place. Stability and basic features inside OpenJFX, experiments and libraries in the ecosystem. - Johan > On 23/02/2024 14.45, Johan Vos wrote: > > I fully agree with John on this. > > A RichTextArea is something that can "easily" be developed outside OpenJFX > . > There are a number of examples already, e.g. RichTextFX, and our (Gluon) > RichTextArea at > https://github.com/gluonhq/rich-text-area > > In the past, we clearly said that this was not a focus for OpenJFX. > > There are a huge amount of outstanding issues in JBS that can only be > fixed in the OpenJFX "core". Developers (of custom components/controls) > rely on the core OpenJFX development to address those issues. That is what > this group (the openjfx-dev list) is supposed to do. > > I highly encourage developers to create custom components and controls, > but not as part of OpenJFX. As others noted as well, we have many other > things to fix that can only be fixed in OpenJFX, and that is where the > priorities of OpenJFX should be, imho. > > - Johan > > On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx <john.hendr...@gmail.com> > wrote: > >> Hi, >> >> Far be it from me to tell the FX team what it should do, I am still >> wondering the following: >> >> - A 3rd party control, RichTextFX already exists -- what is this new >> proposal adding that RichTextFX does not have? >> - What (if anything) is stopping a 3rd party from building a RichTextArea >> themselves? >> >> In other words, I think the FX team ought to focus on **facilitating** >> the building of complex controls like RichTextArea, by identifying gaps in >> the current Control API that is **stopping** 3rd parties from doing this >> themselves in the same integrated manner as a "native" FX control. >> >> Enabling thousands or tens of thousand of developers to build more >> complicated controls seems to me like a much better investment than what I >> think will be a significant investment in one of the most complex controls >> imaginable. RichTextFX was actively developed over a 4 year period, with >> 45 contributors and over 1400 commits (for comparison, JavaFX had 250 >> commits in the past year). If it will be significantly less complicated, >> then what does it offer over RichTextFX? >> >> --John >> On 21/02/2024 19:07, Andy Goryachev wrote: >> >> Dear JavaFX developers: >> >> >> >> We would like to propose a new feature - rich text control, RichTextArea, >> intended to bridge the functional gap with Swing and its >> StyledEditorKit/JEditorPane. The main design goal is to provide a control >> that is complete enough to be useful out-of-the box, as well as open to >> extension by the application developers. >> >> >> >> This is a complex feature with a large API surface that would be nearly >> impossible to get right the first time, even after an extensive review. We >> are, therefore, introducing this in an incubating module, >> *javafx.incubator.richtext*. This will allow us to evolve the API in >> future releases without the strict compatibility constraints that other >> JavaFX modules have. >> >> >> >> Please take a look at the proposal [0], a list of discussion points [1], >> and the API Specification (javadoc) [2]. While the proposed API is ready >> for review, it isn't complete nor set in stone. We are looking for >> feedback, and will update the proposal based on the suggestions we receive >> from the community. We encourage you to comment either in the mailing >> list, or by leaving comments inline in a draft pull request [3]. For >> context, the links to the original RFE [4] and a list of missing APIs >> related to rich text [5] are provided below. >> >> >> >> Sincerely, >> >> Your friendly JavaFX development team. >> >> >> >> >> >> References >> >> >> >> >> >> [0] Proposal: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md >> >> [1] Discussion points: >> https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md >> >> [2] API specification (javadoc): >> https://cr.openjdk.org/~angorya/RichTextArea/javadoc >> >> [3] Draft Pull Request for API comments and feedback: >> https://github.com/openjdk/jfx/pull/1374 >> >> [4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121 >> >> [5] Missing APIs related to rich text control: >> https://bugs.openjdk.org/browse/JDK-8300569 >> >> >> >>
