I already like this suggestion very much, as it is simple, concise and
located exactly where you'd expect it (near `requestFocus`). It offers
the navigation options that FX offers in a programmatic way and doesn't
need to cater to other methods, only what FX offers.
I also have an alternative
On Tue, 22 Oct 2024 05:51:04 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> scanline stride always measured in bytes
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/javax/XImageLo
On Mon, 21 Oct 2024 13:27:08 GMT, Michael Strauß wrote:
>> 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) S
On Mon, 21 Oct 2024 13:27:08 GMT, Michael Strauß wrote:
>> 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) S
> 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 to go, as per normal UI rules) consuming key events that bub
Hello,
Thank you so much for your effort! I'm really glad this hasn't been
forgotten. I wouldn't say it's just popular demand; it's an absolute must.
Here are a few thoughts, if you don't mind.
Every modern platform supports this feature: Electron, Tauri, Wails, Qt,
and even Swing via FlatLaf. If
On Mon, 21 Oct 2024 10:55:53 GMT, Thiago Milczarek Sayao
wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> revert unintended change
>
> A few points observed on Linux:
> 1) It's possible to resize it to 1px using
On Mon, 21 Oct 2024 22:45:28 GMT, Andy Goryachev wrote:
> To clarify about height: do all the platforms support arbitrary height? What
> if size set by the app/CSS exceeds the height supported by the platform?
Yes, all platforms support header bars of arbitrary height. You can make the
header
On Mon, 21 Oct 2024 19:48:56 GMT, Andy Goryachev wrote:
>> Removed "not yet fully implemented" USE_MULTIPLE_NODES and related code.
>>
>> I would like to remove the early unfinished idea of using multiple Text
>> nodes in TextAreaSkin to clean up the code, to make it easier to do fixes
>> for
On Sun, 20 Oct 2024 01:23:01 GMT, Michael Strauß wrote:
>> 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 eff
On Mon, 21 Oct 2024 20:59:00 GMT, Andy Goryachev wrote:
> I suggest we convert this PR to Draft and first discuss this in the mailing
> list.
This has already been
[discussed](https://mail.openjdk.org/pipermail/openjfx-dev/2021-July/031428.html)
at various points in time, and was always recei
I don't want to limit the API choices: someone might come around and say "we
want to add two more directions - clockwise and counterclockwise". The any
code that switches on an enum value without a default case would fail at run
time (a known footgun).
I don't understand why anyone want to swi
> Also, there seems to be little utility in creating the directionality enum -
> the only reason to do so would, in my opinion, be within the context of a
> traversal policy, something that appeared to be very controversial. I can't
> but notice how the example you gave tries to solve the same
> 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
>
On Sun, 20 Oct 2024 01:23:01 GMT, Michael Strauß wrote:
>> 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 eff
Thank you for the feedback and suggestions!
I think adding these methods to Node is not right, for the reasons explained in
the JEP (as it effects changes outside of the said Node).
Also, there seems to be little utility in creating the directionality enum -
the only reason to do so would, in m
On Mon, 21 Oct 2024 20:12:39 GMT, Andy Goryachev wrote:
>> When the initial value of a styleable property is not specified in a
>> stylesheet, no transition is started:
>>
>> .button {
>> transition: -fx-opacity 1s;
>> }
>>
>> .button:hover {
>> -fx-opacity: 0.5
On Sun, 20 Oct 2024 22:08:21 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
On Mon, 21 Oct 2024 15:32:28 GMT, Michael Strauß wrote:
> When the initial value of a styleable property is not specified in a
> stylesheet, no transition is started:
>
> .button {
> transition: -fx-opacity 1s;
> }
>
> .button:hover {
> -fx-opacity: 0.5;
> }
> Removed "not yet fully implemented" USE_MULTIPLE_NODES and related code.
>
> I would like to remove the early unfinished idea of using multiple Text nodes
> in TextAreaSkin to clean up the code, to make it easier to do fixes for
> [JDK-8342233](https://bugs.openjdk.org/browse/JDK-8342233) and
On Mon, 21 Oct 2024 18:38:23 GMT, Kevin Rushforth wrote:
>> Removed "not yet fully implemented" USE_MULTIPLE_NODES and related code.
>>
>> I would like to remove the early unfinished idea of using multiple Text
>> nodes in TextAreaSkin to clean up the code, to make it easier to do fixes
>> for
On Mon, 21 Oct 2024 11:28:23 GMT, Lukasz Kostyra wrote:
>> This PR adds a title-mentioned fallback to `ImageStorage.java` and a test
>> for that specific scenario.
>>
>> In `ImageStorage.loadAll()` we still prefer the Image path that was provided
>> by the user, but if it is missing we will no
On Mon, 21 Oct 2024 18:16:01 GMT, Kevin Rushforth wrote:
>> Removed "not yet fully implemented" USE_MULTIPLE_NODES and related code.
>>
>> I would like to remove the early unfinished idea of using multiple Text
>> nodes in TextAreaSkin to clean up the code, to make it easier to do fixes
>> for
> 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 Wed, 16 Oct 2024 23:01:39 GMT, Andy Goryachev wrote:
> Removed "not yet fully implemented" USE_MULTIPLE_NODES and related code.
>
> I would like to remove the early unfinished idea of using multiple Text nodes
> in TextAreaSkin to clean up the code, to make it easier to do fixes for
> [JDK-
> 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
I think it is a good idea to do the non-controversial part of this
feature first.
With regards to the API, I would prefer a single instance method on Node:
Node moveFocus(FocusTraversalKind);
Where FocusTraversalKind is an enum with values UP, DOWN, LEFT, RIGHT,
NEXT, and PREVIOUS.
Note that
Hi Dani,
Welcome, and thank you for taking a look at this problem.
I don't know enough yet to suggest the best course of action, but I took
a quick look at it. I only see the one call to the native
RenderingQueue::flush -- from freeSpace(int) if autoFlush is true.
RenderingQueue::flush does a
When the initial value of a styleable property is not specified in a
stylesheet, no transition is started:
.button {
transition: -fx-opacity 1s;
}
.button:hover {
-fx-opacity: 0.5;
}
The expected behavior is that a transition is started in this case, since th
On Sat, 19 Oct 2024 16:24:42 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - remove unused code
>> - fix line endings
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/iio/javax/XImag
> 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 Mon, 21 Oct 2024 11:28:23 GMT, Lukasz Kostyra wrote:
>> This PR adds a title-mentioned fallback to `ImageStorage.java` and a test
>> for that specific scenario.
>>
>> In `ImageStorage.loadAll()` we still prefer the Image path that was provided
>> by the user, but if it is missing we will no
> This PR adds a title-mentioned fallback to `ImageStorage.java` and a test for
> that specific scenario.
>
> In `ImageStorage.loadAll()` we still prefer the Image path that was provided
> by the user, but if it is missing we will now try to add a `@1x` suffix to
> Image name and give it one la
On Sat, 19 Oct 2024 15:47:42 GMT, John Hendrikx wrote:
>> I would think that this is acceptable, since that's the exception message
>> that we expect to see (if the `@1x` version also can't be found).
>
> I think the call stack being different is fine; call stacks are there for
> developers to
On Sun, 20 Oct 2024 01:23:01 GMT, Michael Strauß wrote:
>> 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 eff
35 matches
Mail list logo
