Dear José: First of all, I am very excited, thank you for taking effort to look into this! I'll definitely take a look at the code, please forgive me ahead of time it might take some time. To make it slightly easier, would it be possible to create a draft PR please?
When I saw your message, I was still in the process of considering various code folding APIs. I would like to bounce a few ideas off you then. 1. The code folding APIs should be compatible with large models. It is entirely possible that the most use cases will deal with small models (code) that require full text to compute folding ranges (as well as syntax highlighting and other things), but the API should be compatible with large models. I was thinking that the view would query the model for the folding given a range currently in the view. Something like this: List<FoldingRange> getFoldingRanges(int startIndex, int lineCount); This would happen in layoutChildren(), where the cells will get populated accordingly. 2. There is a question of showing the folding toggles - would it be a new sidebar that contains only the toggles, or should the toggles be included in some other component (LineNumberDecorator?) Meaning, should the toggles occupy their own visual column or share this column with other similar things, breakpoint toggles for example? 3. I would strongly suggest that we do not expose VFlow and other currently internal parts to the public right now. I mean we might do it eventually, but right now it will be super counterproductive. A private implementation allows us to iterate and add new features without introducing breaking changes. We can think of opening up the skin details once the feel the project reached a certain maturity level (look, the regular control's skins are not yet fully open!). 4. Speaking of VFlow - in the early days I was considering reusing the VirtualFlow, but decided against it because it was designed for virtual lists/tables and not as a general purpose virtualization mechanism. So maybe one possibility is to extract parts of VFlow into a universal virtual flow component that can deal with scrollbars and conversions between view and model coordinates. Something tells me this might be a complex project on its own... These are just my current thoughts; I'll take a look at your code once the draft PR is there. What do you think? -andy From: José Pereda <[email protected]> Date: Monday, August 24, 2026 at 10:41 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!Op20OCfhdgYGWvirGjOclZFS1I1Zi9ALKqEiWPkrOsCGAffZM9YsYn0_VMdAyj6H1sPj-u88JIC2Ftc26MHUSJzSOg_yOH7W96hPJWCm4eUnI0FQzWKPwCsZhtOYbl4V$> 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<https://urldefense.com/v3/__https://github.com/jperedadnr/jfx/tree/codefolding__;!!ACWV5N9M2RV99hQ!Ixog6-QkDVGzrQLb_pl10ZNZ_c9tY-of81oI4t9lSfFy-7iw9wDZ9qgnCqyQUf8B-cNYc4XbPLNTVKwyuvGhK5FJqqFT$> 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]<mailto:[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]<mailto:[email protected]>> Date: Thursday, August 13, 2026 at 05:10 To: Andy Goryachev <[email protected]<mailto:[email protected]>> Cc: openjfx-dev <[email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]>> Date: Wednesday, August 12, 2026 at 04:40 To: openjfx-dev <[email protected]<mailto:[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! -- -- [http://download.gluonhq.com/mail/josepereda.png] -- [http://download.gluonhq.com/mail/josepereda.png]
