Thanks, Andy! The code folding feature is a complex one, definitely. Even with extensibility in place, if developers had to implement it on their own, that would be quite a challenge! So having it baked into the control is a big plus.
However, my concerns still stand: there is always a missing feature in a control! JavaFX built-in controls have, well, for most parts (as you mentioned, behaviour is still unresolved...), a solid base for extension, that makes it easy for developers to create their own custom controls. Therefore, I believe it is important to define an extensibility path, not only for CodeArea but for the RichTextArea itself. As I mentioned in my previous email, the VFlow/TextCell classes are two important ones to start with. Following the analogy of ListView/Cell classes, defining the required protected/public API for those two would naturally lead to more changes in related classes. In any case, we can keep the discussion here for now, hoping that others will jump in as well. And moving forward, should we file a JBS ticket under the umbrella JDK-8351982, and come up with a basic proposal with a draft PR? Thanks! On Wed, Aug 12, 2026 at 9:28 PM Andy Goryachev <[email protected]> wrote: > 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! > > -- > --
