Re: Gauging interest in bindings that can delay changing their value (debounce/throttle)
I love this idea and would use it immediately!
On Fri, Mar 24, 2023 at 12:10 AM John Hendrikx
wrote:
> Hi list,
>
> I've been working on a potential new API (and proof of concept
> implementation) for adding a new type of fluent binding which can delay
> changing their values, and I'm wondering how much interest there is in
> such a thing.
>
> The main purpose of such an API is to prevent being flooded with changes
> when properties change often, or to simply delay certain actions until
> the user has settled on a selection or has stopped typing.
>
> For this purpose I would like to introduce a default method on
> `ObservableValue` with the signature:
>
> ObservableValue throttle(Throttler throttler);
>
> The parameter `Throttler` can be obtained via static methods of a helper
> class named `FXThrottlers`. These provide various pre-configured
> throttlers that work correctly with JavaFX's event thread model. My
> current proof of concept provides:
>
> public static Throttler debounce(Duration quietPeriod);
> public static Throttler debounceTrailing(Duration quietPeriod);
> public static Throttler throttle(Duration period);
> public static Throttler throttleTrailing(Duration period);
>
> These are variations of similar concepts, and vary mostly in when
> exactly they will allow value changes; debouncers will wait for a period
> without any changes, while throttlers will periodically allow changes.
> The trailing variants will not immediately emit the first change but
> will wait for the period to elapse first; all variants will eventually
> take on the value of the source observable. Debouncing is typically
> used when you wish for an input to settle before taking action (like
> typing in a search bar), while throttling is used to give regular
> feedback but avoid doing so too often (like feedback during window
> resizing).
>
> Usage example which updates a preview panel when the user has finished
> (cursor) scrolling through a list view:
>
> ObjectProperty selectedItem =
> listView.getSelectionModel().selectedItemProperty();
>
> selectedItem
> .throttle(FXThrottlers.debounceTrailing(Duration.ofMillis(500)))
> .addListener((obs, old, current) -> {
> if (current != null) {
> updatePreviewPanel(current);
> }
> });
>
> Implementation details:
>
> ObservableValue is part of javafx.base, and as such can't use animations
> or call Platform::runLater. The ThrottledBinding implementation has
> abstracted all of these out into the Throttler class, and FXThrottlers
> (which would live in javafx.graphics) therefore provides the necessary
> call backs to integrate property changes correctly back onto the JavaFX
> event thread. The Throttler class also simplifies testing; the test can
> provide its own timing source and background scheduler. The Throttler
> interface has the following methods:
>
> /**
> * Schedules a command to run on an unspecified thread after the time
> * given by {@code nanos} elapses.
> *
> * @param command a command to run, cannot be {@code null}
> * @param nanos a time in nanoseconds
> */
> void schedule(Runnable command, long nanos);
>
> /**
> * Provides the current time in nanoseconds.
> *
> * @return the current time in nanoseconds
> */
> long nanoTime();
>
> /**
> * Runs the given command as soon as possible on a thread specified
> by this
> * throttler for updating property values.
> *
> * @param command a command to run, cannot be {@code null}
> */
> void update(Runnable command);
>
> /**
> * Given the current elapsed time in the current change window, and
> the
> * amount of time elapsed since the last change was detected,
> determines
> * if and by how much the current change window should be extended.
> *
> * @param elapsed nanoseconds elapsed since the start of the
> current change window
> * @param elapsedSinceLastChange nanoseconds elapsed since the last
> change
> * @return nanoseconds to extend the window with
> */
> long determineInterval(long elapsed, long elapsedSinceLastChange);
>
> For testing purposes, the schedule and nanoTime can be provided such
> that the throttle function can be tested deterministically. For
> integrating with JavaFX, update is implemented as
> `Platform.runLater(command)`. The schedule and nanoTime methods
> delegate to an Executor and System.nanoTime respectively. When using
> properties without JavaFX, Throttler implementations can be provided
> which run property updates on a scheduler thread (just calling
> Runnable::run on the current thread) or via some user provided executor.
>
> A sample test case looks like this (read with a mono space font :-)):
>
> @Test
> void testThrottleLeadingAndTrailing() {
>// create Throttler with deterministic behavior:
RFR: 8286089: Intermittent WebKit build failure on macOS in JavaScriptCore
Issue: Error copying file (if different) from Source/JavaScriptCore/Scripts/wkbuiltins/builtins_generate_separate_header.py" to "modules/javafx.web/build/mac/Release/JavaScriptCcripts/builtins_generate_separate_header.py". Root cause: The number of build threads more than 8, causing a synchronization issue for builtins_generate_separate_header.py, the file needs to be copied before use at build dir Solution: Use the sleep of 1 second and retry 10 times to copy in CMakeList.txt and execute using the execute_process cmake command - Commit messages: - 8286089: Fix Build error mac osx 11 Changes: https://git.openjdk.org/jfx/pull/1073/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1073&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8286089 Stats: 26 lines in 1 file changed: 26 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jfx/pull/1073.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1073/head:pull/1073 PR: https://git.openjdk.org/jfx/pull/1073
Re: RFR: JDK-8245919: Region#padding property rendering error
On Mon, 27 Mar 2023 23:05:00 GMT, John Hendrikx wrote: > Fix bug in CSS caching code that could reset values on unrelated nodes. > > The bug occurs due to a cache entry being constructed incorrectly when the > initial node that triggered the cache entry creation has user set values. The > calculated values for properties with a user set value were omitted in the > cache entry, and other nodes that later share the same entry would > incorrectly assume the omitted property was unstyled and were therefore reset > to their default values. Note for reviewers: The problem of one Node affecting another unrelated Node is because all properties of the same type, at the same level and same pseudo state set share a cache entry. When the cache entry is constructed based on a Node with an overridden property, the calculated value for the overridden property would be omitted incorrectly -- it is incorrect because other Nodes that would share the same entry may not have this property overridden! The cache entry always should have a complete set of calculated values, regardless of which Node was used to construct the initial cache entry. I removed the user overridden property check in `lookup`. I think this is harmless because both callers of `lookup` do the same check themselves again to avoid applying a style that would override a user set value. However, in `transitionToState` this is just **after** the calculated value is added to the cache, which is exactly what you want. A test verifies that the fix works. - PR Comment: https://git.openjdk.org/jfx/pull/1072#issuecomment-1485983070
RFR: JDK-8245919: Region#padding property rendering error
Fix bug in CSS caching code that could reset values on unrelated nodes. The bug occurs due to a cache entry being constructed incorrectly when the initial node that triggered the cache entry creation has user set values. The calculated values for properties with a user set value were omitted in the cache entry, and other nodes that later share the same entry would incorrectly assume the omitted property was unstyled and were therefore reset to their default values. - Commit messages: - Fix bug in CSS caching code that could reset values on unrelated nodes Changes: https://git.openjdk.org/jfx/pull/1072/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8245919 Stats: 95 lines in 2 files changed: 69 ins; 23 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1072.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1072/head:pull/1072 PR: https://git.openjdk.org/jfx/pull/1072
Re: [External] : Re: Allow input controls to indicate significant user interaction
> I'd think a loss of focus might be considered as a trigger for "significant > interaction". Or perhaps you could give us an example of a use case in which > it'll be insufficient? For example, for a text field, gaining and losing focus is probably sufficient to count as an interaction. Everything that happens between gaining and losing focus can be thought of a as an operation in progress. The same isn't true for a slider: when we click-and-drag, the slider should probably count as being interacted with as soon as the mouse button is released, not when the slider loses focus (the same should be true for key-press-and-hold). Similarly, operations that are immediately completed (like pressing the HOME or END keys on a slider) should most likely also immediately count as a significant interaction. It is true that I can do this without platform support, but it requires me to hard-wire each type of control with its particular behavioral details. > It depends on the application requirements. So, ultimately, the validation > framework that the app developers are going to use must be flexible enough to > handle all the cases. Yes, and ideally, the third-party validation framework would work with all kinds of controls (and even non-controls, as "Control" is a concept that is only introduced with the javafx.controls module), not only the standard controls that come with JavaFX.
Re: Allow input controls to indicate significant user interaction
I should add that aside from the javafx.scene.input.InputNode
interface, there is no addition to or modification of the core
platform.
Nothing in javaxf.graphics uses InputNode, it is provided solely as a
contract for the "significant interaction" information, which
third-party libraries can depend on without depending explicitly on
the javafx.controls module or any particular controls implementation.
On Mon, Mar 27, 2023 at 7:02 PM Kevin Rushforth
wrote:
>
> I also am skeptical regarding the need for API in the core platform to
> support this.
>
> -- Kevin
>
>
> On 3/27/2023 9:46 AM, Andy Goryachev wrote:
>
> I think this functionality belongs to the application-level code, not in the
> platform. It's the application that knows which parts of a form need the
> visual feedback and which do not. In my opinion, there is no APIs that are
> missing in order to implement a validation framework of any level of
> complexity.
>
>
>
> Not responding to programmatic changes is easy: disable validation logic when
> setting values.
>
>
>
> The validation and subsequent user feedback may happen at the time of form
> submission, or as a result of a short timer expiring. The timer should be
> restarted upon each update of the value properties being validated.
>
>
>
> In any case, this problem has a well-defined solution and, in my opinion,
> does not require a change in the core platform.
>
>
>
> Cheers,
>
> -andy
>
>
>
>
>
> From: openjfx-dev on behalf of Michael Strauß
>
> Date: Sunday, March 26, 2023 at 17:49
> To: openjfx-dev
> Subject: Allow input controls to indicate significant user interaction
>
> 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.
>
>
Integrated: 8304924: [testbug] Skip failing tests on Linux
On Sat, 25 Mar 2023 15:50:21 GMT, Kevin Rushforth wrote: > This PR skips three headful tests on Linux until the issues with the tests > can be fixed. These tests consistently fail on our physical Ubuntu 22.04 test > machine. This is a step towards getting clean headful test runs. Each of the > skipped tests has an associated bug that needs to be fixed. This pull request has now been integrated. Changeset: 2a5bf464 Author:Kevin Rushforth URL: https://git.openjdk.org/jfx/commit/2a5bf4647ca19f67eb56f2459f0a5acee6c05146 Stats: 22 lines in 3 files changed: 14 ins; 0 del; 8 mod 8304924: [testbug] Skip failing tests on Linux Reviewed-by: almatvee - PR: https://git.openjdk.org/jfx/pull/1068
Re: [External] : Re: Allow input controls to indicate significant user interaction
Michael: > 2. Just-in-time validation for every significant interaction I'd think a loss of focus might be considered as a trigger for "significant interaction". Or perhaps you could give us an example of a use case in which it'll be insufficient? > when did a user significantly interact with the control? It depends on the application requirements. So, ultimately, the validation framework that the app developers are going to use must be flexible enough to handle all the cases. -andy From: Michael Strauß Date: Monday, March 27, 2023 at 10:19 To: Andy Goryachev Cc: openjfx-dev Subject: [External] : Re: Allow input controls to indicate significant user interaction Hi Andy, thanks for your feedback. It's true that only an application knows which fields require feedback and which don't. That's why I don't propose to create a validation framework in the core platform. However, I don't think your solution addresses the point that I've raised. While using timers to trigger validation is certainly possible, it's not what I was describing; in fact, I would argue that this would be a very bad user experience in most cases. There are basically three kinds of validation semantics that are widely used: 1. Eager validation for every value change 2. Just-in-time validation for every significant interaction 3. Delayed validation at the time of form submission The first and third options have easy solutions in JavaFX applications, but the second option has no good solution. Sure, I can add event listeners to applicable controls and try to find out whether any particular sequence of key strokes or mouse events corresponds to a significant interaction. But that requires me to also consider many different ways in which controls can be significantly interacted with. For example, while I can type text into a text field, I can also paste text using my mouse. It would be very hard for me to detect all these interactions, and there is certainly no well-defined solution, as most aspects of control behavior are delegated to black-box skins in any case. There simply is no reliable way to answer the question that I need to have answered: when did a user significantly interact with the control? On Mon, Mar 27, 2023 at 6:46 PM Andy Goryachev wrote: > > I think this functionality belongs to the application-level code, not in the > platform. It's the application that knows which parts of a form need the > visual feedback and which do not. In my opinion, there is no APIs that are > missing in order to implement a validation framework of any level of > complexity. > > > > Not responding to programmatic changes is easy: disable validation logic when > setting values. > > > > The validation and subsequent user feedback may happen at the time of form > submission, or as a result of a short timer expiring. The timer should be > restarted upon each update of the value properties being validated. > > > > In any case, this problem has a well-defined solution and, in my opinion, > does not require a change in the core platform. > > > > Cheers, > > -andy
Re: Allow input controls to indicate significant user interaction
Hi Andy, thanks for your feedback. It's true that only an application knows which fields require feedback and which don't. That's why I don't propose to create a validation framework in the core platform. However, I don't think your solution addresses the point that I've raised. While using timers to trigger validation is certainly possible, it's not what I was describing; in fact, I would argue that this would be a very bad user experience in most cases. There are basically three kinds of validation semantics that are widely used: 1. Eager validation for every value change 2. Just-in-time validation for every significant interaction 3. Delayed validation at the time of form submission The first and third options have easy solutions in JavaFX applications, but the second option has no good solution. Sure, I can add event listeners to applicable controls and try to find out whether any particular sequence of key strokes or mouse events corresponds to a significant interaction. But that requires me to also consider many different ways in which controls can be significantly interacted with. For example, while I can type text into a text field, I can also paste text using my mouse. It would be very hard for me to detect all these interactions, and there is certainly no well-defined solution, as most aspects of control behavior are delegated to black-box skins in any case. There simply is no reliable way to answer the question that I need to have answered: when did a user significantly interact with the control? On Mon, Mar 27, 2023 at 6:46 PM Andy Goryachev wrote: > > I think this functionality belongs to the application-level code, not in the > platform. It's the application that knows which parts of a form need the > visual feedback and which do not. In my opinion, there is no APIs that are > missing in order to implement a validation framework of any level of > complexity. > > > > Not responding to programmatic changes is easy: disable validation logic when > setting values. > > > > The validation and subsequent user feedback may happen at the time of form > submission, or as a result of a short timer expiring. The timer should be > restarted upon each update of the value properties being validated. > > > > In any case, this problem has a well-defined solution and, in my opinion, > does not require a change in the core platform. > > > > Cheers, > > -andy
Re: RFR: 8304924: [testbug] Skip failing tests on Linux
On Sat, 25 Mar 2023 15:50:21 GMT, Kevin Rushforth wrote: > This PR skips three headful tests on Linux until the issues with the tests > can be fixed. These tests consistently fail on our physical Ubuntu 22.04 test > machine. This is a step towards getting clean headful test runs. Each of the > skipped tests has an associated bug that needs to be fixed. Marked as reviewed by almatvee (Reviewer). - PR Review: https://git.openjdk.org/jfx/pull/1068#pullrequestreview-1359530257
Re: Allow input controls to indicate significant user interaction
I also am skeptical regarding the need for API in the core platform to
support this.
-- Kevin
On 3/27/2023 9:46 AM, Andy Goryachev wrote:
I think this functionality belongs to the application-level code, not
in the platform. It's the application that knows which parts of a
form need the visual feedback and which do not. In my opinion, there
is no APIs that are missing in order to implement a validation
framework of any level of complexity.
Not responding to programmatic changes is easy: disable validation
logic when setting values.
The validation and subsequent user feedback may happen at the time of
form submission, or as a result of a short timer expiring. The timer
should be restarted upon each update of the value properties being
validated.
In any case, this problem has a well-defined solution and, in my
opinion, does not require a change in the core platform.
Cheers,
-andy
*From: *openjfx-dev on behalf of
Michael Strauß
*Date: *Sunday, March 26, 2023 at 17:49
*To: *openjfx-dev
*Subject: *Allow input controls to indicate significant user interaction
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.
Re: Allow input controls to indicate significant user interaction
It's true that a choice needs to be made as to what should be considered a significant interaction. This proposal delegates the choice to skins, as that's where these kinds of choices are generally made. For example, skins also decide when a button's action is invoked, or when a context menu opens. In fact, many of these kinds of semantic choices are internally represented as behavior classes, which are intrinsically tied to skins. Since skins define the behavior of controls, it seems fitting that they should also define what should be a significant interaction for the control. If control authors want to change that, they can create a new skin for that, the same as what one would do to change any other behavioral aspect of a control. On Mon, Mar 27, 2023 at 6:31 PM mkpaz wrote: > > 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.
Re: Allow input controls to indicate significant user interaction
I think this functionality belongs to the application-level code, not in the
platform. It's the application that knows which parts of a form need the
visual feedback and which do not. In my opinion, there is no APIs that are
missing in order to implement a validation framework of any level of complexity.
Not responding to programmatic changes is easy: disable validation logic when
setting values.
The validation and subsequent user feedback may happen at the time of form
submission, or as a result of a short timer expiring. The timer should be
restarted upon each update of the value properties being validated.
In any case, this problem has a well-defined solution and, in my opinion, does
not require a change in the core platform.
Cheers,
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Sunday, March 26, 2023 at 17:49
To: openjfx-dev
Subject: Allow input controls to indicate significant user interaction
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.
Re: Allow input controls to indicate significant user interaction
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.
Re: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState
On Mon, 27 Mar 2023 15:56:52 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
>>
>>> 77: * @return the pseudo class state
>>> 78: */
>>> 79: public Set getPseudoClasses() {
>>
>> does this change need a CSR?
>
> Yes, thanks for checking. I already flagged it as needing a CSR.
oh, sorry, missed the label...
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149470689
Re: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState
On Mon, 27 Mar 2023 15:40:47 GMT, Andy Goryachev wrote:
>> The class `PseudoClassState` is private API, but was exposed erroneously in
>> the CSS API. Instead, `Set` should have been used. This PR
>> corrects this.
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
>
>> 77: * @return the pseudo class state
>> 78: */
>> 79: public Set getPseudoClasses() {
>
> does this change need a CSR?
Yes, thanks for checking. I already flagged it as needing a CSR.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149465925
Re: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState
On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx wrote:
> The class `PseudoClassState` is private API, but was exposed erroneously in
> the CSS API. Instead, `Set` should have been used. This PR
> corrects this.
modules/javafx.graphics/src/main/java/javafx/css/Match.java line 79:
> 77: * @return the pseudo class state
> 78: */
> 79: public Set getPseudoClasses() {
does this change need a CSR?
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1070#discussion_r1149443167
Re: RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState
On Mon, 27 Mar 2023 13:50:40 GMT, John Hendrikx wrote: > The class `PseudoClassState` is private API, but was exposed erroneously in > the CSS API. Instead, `Set` should have been used. This PR > corrects this. This was clearly a mistake back when the public API was first created in JDK 9. - PR Comment: https://git.openjdk.org/jfx/pull/1070#issuecomment-1485291399
Re: RFR: JDK-8304439: Subscription based listeners [v2]
> Makes `Subscription` public (removing some of its methods that are > unnecessary), and adds methods that can provide `Subscription`s in > `ObservableValue`. John Hendrikx has updated the pull request incrementally with one additional commit since the last revision: Move Subscription method for invalidations to Observable - moved Subscription class to the Observable package - Changes: - all: https://git.openjdk.org/jfx/pull/1069/files - new: https://git.openjdk.org/jfx/pull/1069/files/315e158e..df31b3fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=01 - incr: https://webrevs.openjdk.org/?repo=jfx&pr=1069&range=00-01 Stats: 53 lines in 10 files changed: 25 ins; 24 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1069.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1069/head:pull/1069 PR: https://git.openjdk.org/jfx/pull/1069
RFR: JDK-8304933: BitSet (used for CSS pseudo class states) listener management is incorrect
JDK-8304933: BitSet (used for CSS pseudo class states) listener management is incorrect - Commit messages: - Fix spelling error - Fix bug in BitSet listener management Changes: https://git.openjdk.org/jfx/pull/1071/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1071&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304933 Stats: 227 lines in 3 files changed: 224 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jfx/pull/1071.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1071/head:pull/1071 PR: https://git.openjdk.org/jfx/pull/1071
RFR: JDK-8304959: Public API in javafx.css.Match should not return private API class PseudoClassState
The class `PseudoClassState` is private API, but was exposed erroneously in the CSS API. Instead, `Set` should have been used. This PR corrects this. - Commit messages: - Remove references to PseudoClassState (private) in Match (public API) Changes: https://git.openjdk.org/jfx/pull/1070/files Webrev: https://webrevs.openjdk.org/?repo=jfx&pr=1070&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8304959 Stats: 7 lines in 1 file changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jfx/pull/1070.diff Fetch: git fetch https://git.openjdk.org/jfx.git pull/1070/head:pull/1070 PR: https://git.openjdk.org/jfx/pull/1070
