On Wed, 15 Apr 2026 22:36:42 GMT, Andy Goryachev <[email protected]> wrote:

>> ### Summary
>> 
>> This PR adds support for controlling tab stops: the `TAB_STOPS` paragraph 
>> attribute and the `defaultTabStops` property in the `RichTextModel`.  
>> 
>> While adding the paragraph attribute is a trivial process, adding a 
>> model-wide property requires adding of a mechanism to support document 
>> properties (something that was originally omitted in the first incubating 
>> release).  Using the document properties, we can now persist not only the 
>> default tab stops, but also provide the version umber for the storage format 
>> provided by the `RichTextFormatHandler`, which will enable support the 
>> format evolution in the future [0].
>> 
>> To showcase the feature, the `RichEditorDemoApp` gains a visual ruler and 
>> additional dialogs and menus.
>> 
>> <img width="822" height="381" alt="Screenshot 2026-03-04 at 14 00 30" 
>> src="https://github.com/user-attachments/assets/32251846-f11a-4e87-b74a-44c21d629550";
>>  />
>> 
>> 
>> ### Paragraph Attribute
>> 
>> Paragraph-specific tab stops are enabled by:
>> 
>> - `StyleAttributeMap.TAB_STOPS` constant
>> - `StyleAttributeMap.Builder.setTabStops(double ... positions)`
>> 
>> ### Default Tab Stops
>> 
>> After the last paragraph tab stop, or when no paragraph tab stops is set, 
>> the document provides a way to set default tab stops via the model's 
>> `defaultTabStops` property:
>> 
>> These changes support the new property and other document properties:
>> 
>> - document-wide properties support in the `StyledTextModel` base class
>> - `defaultTabStops` property in the `RichTextModel` and 
>> `RichTextFormatHandler`
>> - document properties `VERSION` and `DEFAULT_TAB_STOPS`
>> - `StyledSegment`: `ofDocumentProperties()` factory, 
>> `getDocumentProperties()`
>> 
>> ### Other Improvements
>> 
>> A number of other improvements were made along with the tab stop related 
>> changes:
>> 
>> - `character()`, `paragraph()`, and `document()` factory methods in the 
>> `StyleAttribute` class
>> - `isCharacterAttribute()`, `isParagraphAttribute()`, and 
>> `isDocumentAttribute()` methods in the `StyleAttribute` class
>> - `RichTextArea`: `documentArea` read-only property
>> 
>> 
>> ### Questions to the Reviewers
>> 
>> - should the informational note [0] be added to the repo, and where?  maybe 
>> under `doc-files/controls/RichTextArea` ?
>> 
>> ### References
>> 
>> [0] [Rich Text Area (Incubator) Data Format Version 
>> 2](https://github.com/andy-goryachev-oracle/jfx/blob/8356042.ruler/doc-files/controls/RichTextArea/RichTextArea_DataFormat_v2.md)
>> 
>> ---------
>> - [x] I confirm that I make this contribu...
>
> Andy Goryachev has updated the pull request with a new target base due to a 
> merge or a rebase. The pull request now contains 173 commits:
> 
>  - review comments
>  - Merge branch 'master' into 8356042.ruler
>  - add exports
>  - whitespace
>  - test
>  - doc
>  - change listener
>  - Merge branch 'master' into 8356042.ruler
>  - new document
>  - file
>  - ... and 163 more: https://git.openjdk.org/jfx/compare/e735e23a...1ca1af96

I left a couple comments on the newly added RTA format doc. The rest looks good.

@Ziad-Mid can you be the second reviewer?

doc-files/controls/RichTextArea/RichTextArea_DataFormat_v2.md line 5:

> 3: Andy Goryachev
> 4: 
> 5: <[email protected]>

We generally don't include email addresses in docs committed to the repo.

doc-files/controls/RichTextArea/RichTextArea_DataFormat_v2.md line 23:

> 21: In short, the format is plain text which contains a sequence of segments 
> representing:
> 22: 
> 23: - document properties

I recommend adding a header with a version number before the document 
properties section, instead of making the version number be just another 
document property. It is more future-proof, and easier to sanity check.

doc-files/controls/RichTextArea/RichTextArea_DataFormat_v2.md line 50:

> 48: 
> 49: 
> 50: ## Description

Should this format be part of the JavaFX API specification? If so, we will 
eventually need a normative definition that is part of the javadoc-generated 
API docs.

Related to this, you might consider defining the syntax and grammar of this 
file in some standardized way (e.g., BNF), especially if this becomes part of 
the specification.

doc-files/controls/RichTextArea/RichTextArea_DataFormat_v2.md line 74:

> 72: |:-------|:----------|:-----------
> 73: |tabs    |99.5       |default tab stops in pixels
> 74: |version |v2         |format version, currently `v2`

See earlier comment.

-------------

PR Review: https://git.openjdk.org/jfx/pull/1800#pullrequestreview-4155537774
PR Comment: https://git.openjdk.org/jfx/pull/1800#issuecomment-4298219517
PR Review Comment: https://git.openjdk.org/jfx/pull/1800#discussion_r3125536209
PR Review Comment: https://git.openjdk.org/jfx/pull/1800#discussion_r3125490727
PR Review Comment: https://git.openjdk.org/jfx/pull/1800#discussion_r3125533098
PR Review Comment: https://git.openjdk.org/jfx/pull/1800#discussion_r3125560988

Reply via email to