On Tue, 29 Oct 2024 20:06:24 GMT, Andy Goryachev wrote:
> Getting back to the API, are you ok with dropping the boolean `visible`
> argument and documenting the expectation of the key event?
Yes, I think that's okay.
-
PR Comment: https://git.openjdk.org/jfx/pull/1604#issuecomment
On Mon, 28 Oct 2024 15:01:47 GMT, Andy Goryachev wrote:
> Removes doPrivileged in the following module:
>
> - javafx.controls
>
> See JDK-8342441 for details.
>
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide
> whitespace" option.
modules/javafx.controls/src/mai
On Mon, 28 Oct 2024 15:01:47 GMT, Andy Goryachev wrote:
> Removes doPrivileged in the following module:
>
> - javafx.controls
>
> See JDK-8342441 for details.
>
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide
> whitespace" option.
A second pair of eyes would be
On Tue, 29 Oct 2024 18:14:31 GMT, Michael Strauß wrote:
> Just to complete the picture, I also want to explain why I am strongly
> against making `focusVisible` writable.
I don't disagree, I'm just a bit on the fence if making it writable by proxy is
a good idea then when it is a concept that
On Tue, 29 Oct 2024 00:56:27 GMT, Michael Strauß wrote:
>> This PR removes all doPrivileged calls from `com.sun.javafx.tk**` in the
>> `javafx.graphics` module.
>>
>> Here is a quick overview of what I did for this fix:
>>
>> 1. Changed all simple cases of `doPrivileged((PrivilegedAction) ()
On Mon, 28 Oct 2024 15:01:47 GMT, Andy Goryachev wrote:
> Removes doPrivileged in the following module:
>
> - javafx.controls
>
> See JDK-8342441 for details.
>
> As a helpful hint for reviewers, I recommend reviewing this using the "Hide
> whitespace" option.
This looks good to me. I left a
On Tue, 29 Oct 2024 21:53:06 GMT, Nir Lisker wrote:
> In that case, you are right. I don't have a strong opinion as I am not an
> advanced user of focus. The current behavior is good enough for me.
>
> By the way, if you have multiple scenes in the stage, and each one has its
> own focused nod
On Tue, 29 Oct 2024 21:47:53 GMT, John Hendrikx wrote:
> > > Also something that just occurred to me, but perhaps I'm late to the
> > > party; with the current API being on `Node` you could call
> > > `requestFocusTraversal` on basically any `Node`, even one that is
> > > currently not focused
> Incubating 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 appl
On Tue, 29 Oct 2024 21:31:59 GMT, John Hendrikx wrote:
> ps. the diff for this PR still looks huge here?
Mainly because of TraversalEngine -> TraversalPolicy refactoring and skins.
And yes, one can call requestFocusTraversal on any Node, focusable or not.
There was some language to that effec
On Tue, 29 Oct 2024 21:40:45 GMT, Nir Lisker wrote:
> > Also something that just occurred to me, but perhaps I'm late to the party;
> > with the current API being on `Node` you could call `requestFocusTraversal`
> > on basically any `Node`, even one that is currently not focused. I'm not
> > s
On Mon, 28 Oct 2024 19:20:28 GMT, Andy Goryachev wrote:
>> Public focus traversal API for use in custom controls
>>
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>>
>> This work is loosely based on the patch
>> https://cr.openjdk.org/~jgiles/
On Tue, 29 Oct 2024 21:31:59 GMT, John Hendrikx wrote:
> Also something that just occurred to me, but perhaps I'm late to the party;
> with the current API being on `Node` you could call `requestFocusTraversal`
> on basically any `Node`, even one that is currently not focused. I'm not sure
> i
On Mon, 28 Oct 2024 19:20:28 GMT, Andy Goryachev wrote:
>> Public focus traversal API for use in custom controls
>>
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>>
>> This work is loosely based on the patch
>> https://cr.openjdk.org/~jgiles/
On Tue, 29 Oct 2024 19:33:20 GMT, Andy Goryachev wrote:
> It's one of the falsehoods programmers should be aware of.
>
> But regardless of how they interact with the UI, the focus indicator should
> always indicate the focus owner, no? There might be levels of indication,
> such as grayed focu
> Incubating 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 appl
On Fri, 25 Oct 2024 17:50:34 GMT, Kevin Rushforth wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> break iterator
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/CodeArea.java
On Tue, 29 Oct 2024 00:39:23 GMT, Alexander Zuev wrote:
>> Andy Goryachev has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 41 commits:
>>
>> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>> - break iter
On Tue, 29 Oct 2024 00:37:43 GMT, Alexander Zuev wrote:
>> Andy Goryachev has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 41 commits:
>>
>> - Merge remote-tracking branch 'origin/master' into 8301121.RichTextArea
>> - break iter
On Fri, 25 Oct 2024 17:32:40 GMT, Kevin Rushforth wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> break iterator
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/TextPos.java
On Tue, 29 Oct 2024 17:55:55 GMT, Michael Strauß wrote:
> users of a GUI will interact with a mouse (or touch), not with the keyboard.
It's one of the falsehoods programmers should be aware of.
But regardless of how they interact with the UI, the focus indicator should
always indicate the foc
On Mon, 28 Oct 2024 19:20:28 GMT, Andy Goryachev wrote:
>> Public focus traversal API for use in custom controls
>>
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>>
>> This work is loosely based on the patch
>> https://cr.openjdk.org/~jgiles/
On Tue, 29 Oct 2024 17:50:17 GMT, Andy Goryachev wrote:
>> Is there really no conceivable scenario in which this method could
>> legitimately be called _not_ in response to a key event, or is it simply
>> that we're not thinking of such a scenario right now? I'd be bothered by an
>> API that w
On Tue, 29 Oct 2024 17:46:48 GMT, Michael Strauß wrote:
>>> What happens when a different type of event is created by a `KeyEvent`
>>> handler? How does the downstream code differentiate between the secondary
>>> events coming from a key event handler vs. from one originated normally?
>>
>> Th
On Tue, 29 Oct 2024 17:44:21 GMT, Andy Goryachev wrote:
> A general question: what would be an example of when `focused !=
> focusVisible` (and `!= focusWithin`) ?
>
> Shouldn't the `focused` be a sort of "primary" property, and all other
> derived from it?
>
> What is the purpose of `focusVi
On Mon, 28 Oct 2024 19:20:28 GMT, Andy Goryachev wrote:
>> Public focus traversal API for use in custom controls
>>
>> https://github.com/andy-goryachev-oracle/Test/blob/main/doc/FocusTraversal/FocusTraversal-v3.md
>>
>> This work is loosely based on the patch
>> https://cr.openjdk.org/~jgiles/
On Tue, 29 Oct 2024 16:07:17 GMT, John Hendrikx wrote:
>> That seems reasonable, given that it is the expected use case. I wouldn't
>> say "_must_ be called", but rather that it "is _expected_ to be called" in
>> response to a KeyEvent, and then document the behavior accordingly --
>> namely,
On Tue, 29 Oct 2024 17:03:01 GMT, Jeanette Winzenburg
wrote:
>> I think this discussion is not productive. Can we focus on essentials
>> please?
>
> readability __is__ essential ;) Same as others, wondering why you insist on
> not going to max it?
I agree with readability. At the same time,
On Tue, 29 Oct 2024 15:28:39 GMT, Andy Goryachev wrote:
>> I agree that especially when each switch case is on a single line, indenting
>> is the most sensible thing to do. It's a little more defensible to treat the
>> standard switch `case :`, on a line by itself, as a label which is
>> p
On Tue, 29 Oct 2024 16:51:33 GMT, Andy Goryachev wrote:
>> I'm not sure why this is a counter argument. It's not used in the JDK or
>> JavaFX. I still think option 2 is better, but if we don't enforce a style
>> then it's your choice.
>
> I think this discussion is not productive. Can we focus
On Fri, 25 Oct 2024 17:31:30 GMT, Kevin Rushforth wrote:
>> Andy Goryachev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> break iterator
>
> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/SideDecorator
On Tue, 29 Oct 2024 16:15:45 GMT, Nir Lisker wrote:
>> That isn't an example of "everything on one line". That's effectively the
>> "switch case :, on a line by itself", which is defensible, although
>> still not preferred.
>>
>> Anyway, what you currently have is what I called option 1, a
On Tue, 29 Oct 2024 13:39:15 GMT, Johan Vos wrote:
> 8331616: ChangeListener is not triggered when the InvalidationListener is
> removed
Looks clean :)
-
Marked as reviewed by jhendrikx (Reviewer).
PR Review: https://git.openjdk.org/jfx21u/pull/74#pullrequestreview-2402409124
On Tue, 29 Oct 2024 15:21:50 GMT, Kevin Rushforth wrote:
>> What happens when a different type of event is created by a `KeyEvent`
>> handler? How does the downstream code differentiate between the secondary
>> events coming from a key event handler vs. from one originated normally?
>>
>>> Is
On Mon, 28 Oct 2024 15:01:20 GMT, Prasanta Sadhukhan
wrote:
> When AWT toolkit is started first for it to own the "NSApplication" and then
> FX toolkit is started and shutdown by calling `Platform.exit` and then Swing
> Dialog is tried to be created, then it is seen that the application crashe
On Tue, 29 Oct 2024 16:00:43 GMT, Kevin Rushforth wrote:
>> Sure:
>>
>>
>> String s = switch(val) {
>> case 1 ->
>> "one";
>> case 2 ->
>> "two";
>> default ->
>> "unknown";
>> };
>
> That isn't an example of "everything on one line". That's effectively the
> "switch case :, on
On Tue, 29 Oct 2024 15:16:59 GMT, Kevin Rushforth wrote:
>> This is a bit silly. You have an opening brace, you should be indenting as
>> you would in every other case when an opening brace appears and you break
>> off the line. So unless there is a **really** good reason to suddenly not
>>
On Tue, 29 Oct 2024 14:45:53 GMT, Andy Goryachev wrote:
>> I think it could be possible, but I'm not sure if it would be pretty. Scene
>> is the one dispatching these events, and since FX has a single threaded
>> model, Scene could have a flag that indicates it is currently dispatching a
>> k
On Mon, 28 Oct 2024 22:36:50 GMT, John Hendrikx wrote:
>>> I don't indent case labels inside of switch.
>>
>> Our typical code style is to indent. I don't have a strong preference, but I
>> switched (pun intended) many years ago from not indenting to always
>> indenting because: A) the IDEs (a
On Tue, 29 Oct 2024 13:01:08 GMT, John Hendrikx wrote:
>> This is better than the previous, since it only asks the caller of this
>> method, typically the Skin of a custom control, to provide the one missing
>> piece of information -- whether or not the method is in response to keyboard
>> nav
8331616: ChangeListener is not triggered when the InvalidationListener is
removed
-
Commit messages:
- Backport 35880cec5a998598c64eecbc7b3ae56b6ee3a6d8
Changes: https://git.openjdk.org/jfx21u/pull/74/files
Webrev: https://webrevs.openjdk.org/?repo=jfx21u&pr=74&range=00
Issue:
On Tue, 29 Oct 2024 11:37:19 GMT, Johan Vos wrote:
> I'm still not convinced having an RTA control inside the same repository as
> the core components on OpenJFX is a good idea.
I think there is value in having a basic, extensible RTA control in the jfx
repo, but one reason it is being propose
On Tue, 29 Oct 2024 12:23:59 GMT, Kevin Rushforth wrote:
>> How about this for `focusVisible`:
>>
>> /**
>> * Indicates whether this {@code Node} should visibly indicate focus.
>> *
>> * This flag is set when the node is {@link #focusedProperty() focused}
>> via keyboard nav
On Mon, 28 Oct 2024 23:53:44 GMT, Michael Strauß wrote:
>> Perhaps we need to further clarify what the focused/focusVisible/focusWithin
>> properties are for?
>
> How about this for `focusVisible`:
>
> /**
> * Indicates whether this {@code Node} should visibly indicate focus.
> *
On Mon, 28 Oct 2024 23:01:39 GMT, Andy Goryachev wrote:
>> Incubating 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
>> u
On Mon, 28 Oct 2024 23:01:39 GMT, Andy Goryachev wrote:
>> Incubating 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
>> u
46 matches
Mail list logo
