Dear José: Yes, the code folding is probably the next thing being planned (please see [0] if there are other items that should take priority, feel free to comment). One thing I should mention is that we could use some help in defining the interface suitable for most use cases. For example, most of the editors I've been involved with do not handle large models well, and one of the design goals of the RichTextArea was to support large models. If you have any suggestions for the API, we would very much like to hear it.
You are right about the relative freedom we currently have with the API changes because of the incubator module. Your question about separation line between public APIs and hidden implementation is a good very one. In fact, it was one of my gripes with javafx vs swing is that it was nearly impossible to make minor adjustments to the implementation or behavior. The major reason the implementation detail is hidden in javafx is that it significantly reduces the maintenance burden and add to stability of the platform, at the expense of flexibility. Javafx made one baby step in the right direction by making the skins public, but it was done without completing other steps that would have enabled customization of the skin. I've tried to make the next step in this direction by proposing the public InputMap [1] . The input map will not help in adding folding to the CodeArea, but it does provide an extra level of customization when no extra control surfaces are needed in the default skin. I would insist on the InputMap for controls in general, but that's a different topic. We *could* attempt to forgo the usual practice and open up the skin and its internals, making VFlow and related classes a public API. On one hand, it might help short term by allowing deeper customization, but at the same time it might cause more problem down the road when a substantial change in the implementation or public API is needed. A better alternative is to focus on missing APIs that would enable the desired functionality (via plug-ins like TabStopPolicy, for instance). Yet another alternative would be to fork the skin and the behavior under GPL. Getting back to folding, I think it should be made a part of the standard offering in CodeArea (I don't exactly know whether it is needed or can be implemented generically as part of RichTextArea). This way, the application does not have to mess with the internals and risk compatibility issues. Sorry for a long response. To summarize, 1. you have the power to influence the design by offering feedback and suggestions 2. we can still make drastic changes while the project is incubating 3. our goal is to make a useful component that works for majority of use cases Your feedback is welcome and very much appreciated. Please let me know what you think. -andy References [0] https://bugs.openjdk.org/browse/JDK-8351982 RichTextArea (Incubator) Feedback and Bugs in jfx24-25 [1] https://github.com/openjdk/jfx/pull/1495 8314968: Public InputMap (v3) From: José Pereda <[email protected]> Date: Wednesday, August 12, 2026 at 04:40 To: openjfx-dev <[email protected]> Subject: [External] : RichTextArea/CodeArea extensibility While working with the CodeArea control, if developers want to implement missing features like code folding ( https://bugs.openjdk.org/browse/JDK-8355957) on their own, that is currently not possible because relevant classes (like VFlow, TextCell, CellArrangement, RichTextAreaBehavior, ...) are in the private, non-exported package com.sun.jfx.incubator.scene.control.richtext. First question: once the incubator module is ready to be moved to a permanent module, is the intention to keep com.sun.jfx.incubator.scene.control.richtext as a private, non-exported package (in its new place)? It currently holds around 40 classes, most of which don't need access to com.sun.* classes outside its module. If that is the case, projects using RTA/CodeArea would need a way to access and extend at least the skin layer. Although the CodeAreaSkin class is public, one of its core classes, VFlow, is in a private package, and is final. It should probably follow the VirtualFlow case: a non-final class in a public package with protected methods. The same applies to the TextCell class (compared to the Cell classes). However, if there is still time to make some changes and move some of those classes to a public scene.control.richtext package, these would be some of the required changes that would allow implementing the code folding feature, and would definitely help developers customize the control in many other different ways: - Move classes to the public skin package, scene.control.richtext.skin: VFlow, TextCell, CellArrangement, CaretInfo, Origin (and the few types their signatures expose), and provide skin factories: RichTextAreaSkin.createVFlow() / createBehavior() (protected), and protected getVFlow() (again, similar to how it is done for instance in ListViewSkin/VirtualFlow). - Row-mapping: this would require changing every "row index == paragraph index" assumption in VFlow/CellArrangement with an overridable mapper, that would default to identity. - TextCell extensibility: public package, non-final, with protected hooks to be able to add inline segments and a visual to and from document position mapping used by hit testing / caret / selection. - Protected geometry & navigation methods in VFlow and in the behavior, so subclasses can modify the default implementation. Are there any plans already to address any of these changes? Is it possible to consider any or all of them in the near future? I realize these are substantial changes, but precisely that is one of the benefits of being an incubator module, isn't it? Thanks! --
