> This PR removes support for running JavaFX applications with the Java
> Security Manager.
>
> The initial work was done in 4 separate commits as follows:
>
> * Fail fast at startup if the Security Manager is enabled
> * Remove `-Djava.security.manager` and all security policy files; delete
>
I think we just need a good name. I agree that "predict" isn't the API
we want.
How about "requestFocusTraversal"? It has symmetry with requestFocus.
-- Kevin
On 10/23/2024 11:05 AM, Andy Goryachev wrote:
I don't think prediction should be the functionality we want in the
Node. This funct
> 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/8061673/
>
> And is a scaled down version (with the public trav
Maybe we can polish the naming a bit:
When used as a transitive verb, "traverse" means (according to
Merriam-Webster): to go or travel across or over, to move or pass
along or through.
MW gives the example: "light rays traversing a crystal". So one thing
is moving (light rays), while the other th
How about „predictFocus“, which will return a Node without changing focus?
This would give applications even more flexibility, because they can then
decide if they want to go ahead and actually change focus by calling
predictFocus()?.requestFocus()
Andy Goryachev schrieb am Mi. 23. Okt. 2024 um
On Wed, 23 Oct 2024 18:48:47 GMT, Kevin Rushforth wrote:
>> Andy Goryachev has updated the pull request with a new target base due to a
>> merge or a rebase. The incremental webrev excludes the unrelated changes
>> brought in by the merge/rebase. The pull request contains 13 additional
>> comm
While I like "tryXYZ", I notice that this style of method naming has
no precedence in the public API of JavaFX.
This is my ranking of the names suggested so far:
1. moveFocus: short and concise, may be a bit assertive
2. requestFocusTraversal: a bit wordy, but says what it'll do
3. tryMoveFocus: g
On Wed, 23 Oct 2024 18:37:03 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/
> This PR is an improved version of #1093.
>
> JavaFX can load BMP, GIF, PNG, and JPEG images with its built-in image
> loaders. It has been a long-standing request to support more image formats,
> most notably (but not limited to) SVG. However, adding more built-in image
> loaders is a signifi
On Tue, 22 Oct 2024 05:21:47 GMT, John Hendrikx wrote:
>> This change modifies `ScrollPaneBehavior` to only consume keys that are
>> targetted at it. As `KeyEvent`s are in almost all cases only intended for
>> the targetted node (as visually that's where the user expects the keyboard
>> input
Ok, thanks.
Have a blessed day.
> On Oct 23, 2024, at 12:54 PM, Michael Strauß wrote:
>
> Don’t worry about the JBS ticket for now. You can create a branch on your own
> JFX fork and give it whatever name you want. If this proceeds, you’ll later
> create a PR from your personal branch to the
> This PR is a new take on a highly requested feature: JavaFX controls in the
> header bar (see also #594 for an earlier iteration).
>
> This is a feature with many possible ways to skin the cat, and it has taken
> quite a bit of effort to come up with a good user model. In contrast to the
> pr
I like "try" very much, does not clash with multiple requestXXX in
autocompletion.
tryMoveFocus(TraversalDirection.UP);
-andy
From: openjfx-dev on behalf of Nir Lisker
Date: Wednesday, October 23, 2024 at 11:54
To: Kevin Rushforth
Cc: openjfx-dev@openjdk.org
Subject: Re: Proposal: Focus
On Mon, 14 Oct 2024 23:31:29 GMT, Andy Goryachev wrote:
>> The RichTextArea control
>> ([JDK-8301121](https://bugs.openjdk.org/browse/JDK-8301121)), or any custom
>> control that needs non-trivial navigation within complex or wrapped text
>> needs a public API to get information about text lay
>
> My only problem with a more assertive “moveFocus” is that it implies a
> success
True, but the JDK already uses it everywhere. Mutation methods on
collections are all named as definitive actions even if they don't succeed.
In general, setters might also fail (usually in the case of NPE), but
On Wed, 9 Oct 2024 13:27:02 GMT, Thiago Milczarek Sayao
wrote:
>> Wayland implementation will require EGL.
>>
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails,
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>>
>>
>> See:
>> [Switching the
On Wed, 9 Oct 2024 13:27:02 GMT, Thiago Milczarek Sayao
wrote:
>> Wayland implementation will require EGL.
>>
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails,
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>>
>>
>> See:
>> [Switching the
Sounds good to me.
Kevin Rushforth schrieb am Mi. 23. Okt. 2024
um 20:15:
> I think we just need a good name. I agree that "predict" isn't the API we
> want.
>
> How about "requestFocusTraversal"? It has symmetry with requestFocus.
>
>
> -- Kevin
>
>
> On 10/23/2024 11:05 AM, Andy Goryachev wr
I don't think prediction should be the functionality we want in the Node. This
functionality, in my opinion, belongs to the traversal policy.
All we want is to navigate away from the specified node.
It might have been easier had we kept the original FocusTraversal class - not
only one can add
I think we don't need separate ConditionalFeatures, because an
application that supports one type of app menu item will support all
of them. Maybe something like ConditionalFeature.APPLICATION_MENU will
suffice.
In addition to that, I've looked at several other applications, and
most of them have
Don’t worry about the JBS ticket for now. You can create a branch on your
own JFX fork and give it whatever name you want. If this proceeds, you’ll
later create a PR from your personal branch to the JFX master branch, and
we can get the JBS ticket sorted out then.
David Kopp schrieb am Mi. 23. O
That is a good question. I need to look into what Ubuntu does in that regard.
I only really looked at the SDK code for the MacApplication.
I think it would be helpful for someone to create a bug tracker issue so we
could create a branch to start working on various approaches.
> On Oct 23, 2024
May be a simple traverse(TraversalDirection) would suffice?
-andy
From: openjfx-dev on behalf of Michael Strauß
Date: Wednesday, October 23, 2024 at 10:05
To:
Cc: openjfx-dev@openjdk.org
Subject: Re: Proposal: Focus Traversal API
Maybe we can polish the naming a bit:
When used as a transitiv
Thank you for suggestion!
My only problem with a more assertive “moveFocus” is that it implies a success,
while this API may or may not succeed (similarly to requestFocus).
The word "shift" in "shiftFocus" might clash with the "shift" key, don't really
like that.
Maybe "requestTraversal" altho
Hi Andy,
I think this updated proposal is a good one. It provides the minimum API
to allow applications to do what they cannot do today, without locking
us into the API needed to directly support traversal policies or
defining new traversal events. Those could be added in a future release,
if
> I presume that the preferred width and height of HeaderBarBase is the
> width of the window and the height of the system-reserved area for
> window buttons?
HeaderBarBase is a resizable `Region`, and as such has no preferred
width or height. It is an abstract base class that is only intended to
Hi Michael,
I like this proposal overall. It provides a commonly-requested feature
with a minimal API surface. While I share some of the concerns about
implementing it, it is reflective of modern UI design on all of the
desktop platforms, so I expect the platform vendors to continue
supportin
On Mon, 21 Oct 2024 18:53:20 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
Michael, would you be willing to create an issue in the JavaFX issue tracker so
I could start working on this?
Have a blessed day,
David Kopp
> On Oct 14, 2024, at 7:29 PM, David Kopp wrote:
>
> I have looked into the Desktop API implementation in the JDK. They have their
> own code to man
On Wed, 9 Oct 2024 13:27:02 GMT, Thiago Milczarek Sayao
wrote:
>> Wayland implementation will require EGL.
>>
>> EGL works with Xorg as well. The idea is to be EGL first and if it fails,
>> fallback to GLX. A force flag `prism.es2.forceGLX=true` is available.
>>
>>
>> See:
>> [Switching the
Michael,
I trust you on this one. I'm just throwing out some ideas, so maybe It
triggers a better idea :)
Ensemble8 has the "Advanced Stage" example. While it's a little unpractical
for a production application, some developers
might want to have different shapes of stages. So maybe it could be a
31 matches
Mail list logo
