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! --
