Hi Andy, following up on the topic, I took some time to work on some possible changes for the richtext module, according to what I described in my initial email, and that is in the RFE https://bugs.openjdk.org/browse/JDK-8390346.
TL;DR: See https://github.com/jperedadnr/jfx/tree/codefolding for code changes, javadoc, basic tests and a new demo application (headings-demo). Detailed summary: I'll classify the changes into three main parts: 1. Scope changes for skin related classes (directly related to https://bugs.openjdk.org/browse/JDK-8390346) I've moved VFlow, CellArrangement, TextCell classes (and a few others) from com.sun.jfx.incubator.scene.control.richtext into the jfx.incubator.scene.control.richtext.skin package, making most of its public methods private or package-private, and only keeping public/protected the methods that serve as extension hooks, and creating some factories. 2. Mapping between view and model (partly related to https://bugs.openjdk.org/browse/JDK-8355957) I've added a RowMap class to the skin package, which maps the rendered paragraphs (view) to the document paragraphs (model). By default, the mapping is 1:1, so nothing changes, but subclasses can provide custom logic to hide paragraphs as needed. It plays the same role as a FilteredList to ListView. 3. Demo app As a working simple demo of both parts. I've added the Heading demo app, which customizes the RTA to allow showing/hiding document sections on demand, and validates the above changes. While I understand from previous conversations that JDK-8355957 is planned and will be added to the richtext module at some point, the scope of these changes would precisely ease such implementation: the foundation for a complex feature like that will already be set, and only the particular details (i.e., the fold() API, the concrete FoldRowMap implementation, etc.) will be needed. In any case, the extensibility changes would allow developers to modify the control when/as they need, without waiting for the long iteration cycles that an RFE usually takes. Moving forward, I'd like to propose three PRs, starting with the scope changes (no RowMap yet), then the RowMap and implementation detail, and finally the demo app. What do you think? On Fri, Aug 14, 2026 at 1:12 AM Andy Goryachev <[email protected]> wrote: > > there is always a missing feature in a control! > > So true. > > I've filed https://bugs.openjdk.org/browse/JDK-8390346 RFE. > > Thank you, and keep the feedback coming! > > -andy > > > > > *From: *José Pereda <[email protected]> > *Date: *Thursday, August 13, 2026 at 05:10 > *To: *Andy Goryachev <[email protected]> > *Cc: *openjfx-dev <[email protected]> > *Subject: *Re: [External] : RichTextArea/CodeArea extensibility > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > <https://us-phishalarm-ewt.proofpoint.com/EWT/v1/ACWV5N9M2RV99hQ!Op20OCfhdgYGVv2tP3z6lyCkjQs8Cg_xSyki_NWBBDU_fJjXTdQow62a5dsIGsyHjkx10C2NV7uJbadwPDjvQYOpjDX8iXr1toqkTQ-W1Td8Mbnic5I9XXDDPez_FTT5$> > > 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 > <https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/1495__;!!ACWV5N9M2RV99hQ!MNwHT4TaNozadxgENEr7zLVqmPnS4dgoPLVhzNjRTod0V507LdZ4xjxiOb4HzGvn0IbW77kUjvfOCV_b5UXsygD40dhS$> > 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! > > -- > > > > -- > --
