Re: Proposal: RichTextArea Control (Incubator)

[mkpaz]

Hello,

>> A 3rd party control, RichTextFX already exists -- what is this new 
proposal adding that RichTextFX does not have?


It uses the standard JavaFX VirtualFlow API and and does not need to 
work with reactive streams. RichtextFX depends on several long 
unmaintained libs: ReactFX (last commit 8 years ago), WellBehavedFX 
(last commit 6 years ago), UndoFX (last commit 3 years ago). To say it's 
actively maintained is a big exaggeration.


>> What (if anything) is stopping a 3rd party from building a 
RichTextArea themselves?


- The lack of a standard API. The Behavior API has been discussed for 
ages, but is still not implemented. Moreover, WellBehavedFX is literally 
a rejected JEP/CSR implementation.
- The closedness of JavaFX in general. All internals are explicitly 
private and final. A few simple examples. The date picker popup uses a 
private API to calculate its width based on text size, but you're 
forbidden to do the same thing. All i18n resources are not exported, 
you're forbidden to use them to create a context menu. You're not 
encouraging 3rd party libs, you're going in the opposite direction (for 
the sake of stability of course).
- The JavaFX community is very small. The "tens of thousands of 
developers" you talk about don't exist. Even famous projects are poorly 
maintained or not maintained at all, including ControlsFX and 
ScenicView. You have fewer features -> you have fewer users/market share 
-> you have less promotion -> you have fewer committers -> you have 
fewer features. It's that simple.
- There's literally no docs about creating new controls. Even Skin API 
is badly documented. You can only learn from existing control libs.


This particular feature would be a HUGE step forward. I'm really glad to 
see it. Hopefully it won't get buried under a bunch of pointless 
abstract discussions like the CSS theme CSR. Just get some feedback and 
implement it the way you want. It's a million times better than doing 
nothing.


On 23/02/2024 14.45, Johan Vos wrote:

I fully agree with John on this.

A RichTextArea is something that can "easily" be developed outside 
OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our 
(Gluon) RichTextArea at

https://github.com/gluonhq/rich-text-area

In the past, we clearly said that this was not a focus for OpenJFX.

There are a huge amount of outstanding issues in JBS that can only be 
fixed in the OpenJFX "core". Developers (of custom 
components/controls) rely on the core OpenJFX development to address 
those issues. That is what this group (the openjfx-dev list) is 
supposed to do.


I highly encourage developers to create custom components and 
controls, but not as part of OpenJFX. As others noted as well, we have 
many other things to fix that can only be fixed in OpenJFX, and that 
is where the priorities of OpenJFX should be, imho.


- Johan

On Fri, Feb 23, 2024 at 2:48 AM John Hendrikx 
 wrote:


Hi,

Far be it from me to tell the FX team what it should do, I am
still wondering the following:

- A 3rd party control, RichTextFX already exists -- what is this
new proposal adding that RichTextFX does not have?
- What (if anything) is stopping a 3rd party from building a
RichTextArea themselves?

In other words, I think the FX team ought to focus on
**facilitating** the building of complex controls like
RichTextArea, by identifying gaps in the current Control API that
is **stopping** 3rd parties from doing this themselves in the same
integrated manner as a "native" FX control.

Enabling thousands or tens of thousand of developers to build more
complicated controls seems to me like a much better investment
than what I think will be a significant investment in one of the
most complex controls imaginable.  RichTextFX was actively
developed over a 4 year period, with 45 contributors and over 1400
commits (for comparison, JavaFX had 250 commits in the past
year).  If it will be significantly less complicated, then what
does it offer over RichTextFX?

--John

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose a new feature - rich text control,
RichTextArea, intended to bridge the functional gap with Swing
and its StyledEditorKit/JEditorPane.  The main design goal is to
provide a control that is complete enough to be useful out-of-the
box, as well as open to extension by the application developers.

This is a complex feature with a large API surface that would be
nearly impossible to get right the first time, even after an
extensive review.  We are, therefore, introducing this in an
incubating module, *javafx.incubator.richtext*. This will allow
us to evolve the API in future releases without the strict
compatibility constraints that other JavaFX modules have.

Please take a look at the proposal [0], a list of discussion
points [1], and 

Re: Allow input controls to indicate significant user interaction

[mkpaz]

I can compare this with Vuetify framework, generally because it uses 
good abstractions. It provides the three types of validation.


1. Eager - an input is validated immediately after loading (adding to 
the scene). Usually it's initialized with some default valid value to 
not disturb user.
2. Input - an input is validated after a user interaction (lazy 
validation). It puts the input to the *dirty state* and that state is 
used to trigger the validation.

3. Submit - an input is validated after the form submission.

While it's already possible to implement the second option, one "simply" 
need to subscribe to all focus, keyboard and mouse events and manage the 
dirty state manually, it seems reasonable to delegate this work to the 
skins. The question is what should be considered as a "significant 
interaction". Some implementations set dirty state immediately after the 
input loses focus state, others require some actual keyboard input.


On 3/27/23 04:48, Michael Strauß wrote:

Many form-based applications require some sort of data validation for
input controls. It is also often desirable to visualize the validation
state of a control directly in the user interface, for example by
showing a red border to indicate a validation failure.

However, simply validating the current value of a control and
rendering a validation decorator often leads to an undesirable user
experience: for example, in many cases an empty form field shouldn't
indicate a validation failure unless the user has significantly
interacted with the field, or validation was explicitly requested by
pressing a "submit" button.

The first of these validation conditions, "significantly interacted
with the input control" is quite popular on contemporary web forms,
and offers a balanced user experience compared to immediately and
eagerly validating every control, or delaying validation until the
very end of the form submission process (see also the proposed
:user-valid/:user-invalid CSS pseudo-classes).

Unfortunately, this is very hard to implement in JavaFX since controls
have no way of signalling when they were significantly interacted
with. In particular, we don't want to count programmatic
initialization of field values as a significant interaction. What
constitutes a significant interaction is dependent on the type of
input control. For example, a text field might define a significant
interaction as the sequence of gaining focus, receiving a new text
value, and losing focus. A slider might define a significant
interaction as the sequence of pressing the mouse button, dragging the
slider thumb to a new value, and releasing the mouse button.

The information of how an input control changed its value is only
really knowable by its skin and associated behavior classes, both of
which are basically black boxes for a JavaFX application. In order to
expose this information, I propose to add the following new interface
in the "javafx.scene.input" package:

public interface InputNode {
 ReadOnlyBooleanProperty userModifiedProperty();
 boolean isUserModified();
 void setUserModified(boolean value);
}

This interface identifies a node that can receive user input. It is
implemented by the following controls: ButtonBase, ChoiceBox,
ComboBoxBase, Slider, Spinner, and TextInputControl.

The associated skins and behaviors are modified to invoke
setUserModified(true) on the control when a significant user
interaction is detected. Once this flag is set on a control, it can
only be unset programmatically from application code by invoking
setUserModified(false).

You might note that userModifiedProperty() returns
ReadOnlyBooleanProperty, while a public setter is availabe. The reason
for this is that while applications should be able to set or clear the
userModified flag programmatically, they shouldn't be able to bind the
property to prevent it from being set by skins.

Note also that it is not a goal of this proposal to add a data
validation framework to JavaFX (this is best left to third-party
libraries instead). The goal is to expose a crucial piece of
information that is not easily accessible otherwise.

I'm interested on your thoughts on this idea.