On Mon, 4 Aug 2025 16:01:54 GMT, Andy Goryachev
wrote:
> John,
>
> Thank you for continuing this discussion. This particular response might need
> its own thread and a topic (FocusTraversalPolicy).
>
> I want to emphasize that JavaFX should provide support for "crazy" as you put
> it require
On Fri, 1 Aug 2025 21:18:53 GMT, Andy Goryachev
wrote:
> There is more: I think the kind of issues we see stem from the sub-optimal
> event dispatching mechanism in JavaFX, the weirdest part of which is creating
> multiple event instances for the same event.
You've mentioned this a number of
On Thu, 17 Jul 2025 05:18:28 GMT, Michael Strauß wrote:
>> Implementation of [focus
>> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Avoid va
On Sun, 15 Jun 2025 14:23:27 GMT, Marius Hanl wrote:
> When calling `refresh()` on virtualized Controls (`ListView`, `TreeView`,
> `TableView`, `TreeTableView`), all cells will be recreated completely,
> instead of just refreshing them.
>
> This is because `recreateCells()` of the `VirtualFlow
On Thu, 31 Jul 2025 01:20:06 GMT, Michael Strauß wrote:
> _Mailing list message from [Andy Goryachev](mailto:andy.goryac...@oracle.com)
> on [openjfx-dev](mailto:openjfx-...@mail.openjdk.org):_
>
> I think I narrowed down my objection to this proposal. My main problem with
> it is that it trie
On Wed, 23 Jul 2025 15:43:32 GMT, John Hendrikx wrote:
> This pull request contains a backport of commit
> [7b59ebce](https://github.com/openjdk/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb)
> from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>
> T
This pull request contains a backport of commit
[7b59ebce](https://github.com/openjdk/jfx/commit/7b59ebcec74cf3e0da25e35b22a9722b9d93ebdb)
from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
The commit being backported was authored by John Hendrikx on 23 Jul 2025 and
was reviewed
For investigating a bug, what I usually do is copy the
control/skin/class/etc in question into my current project, leaving it
in its original package. This effectively overwrites that class,
allowing you to make edits to it (like adding debug prints, or altering
calculations). This works pretty e
On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx wrote:
> This PR fixes a regression introduced in #1723
>
> It reverts the changes made in the BorderPaneTest with new comments
> explaining why the values are what they are. It only fixes the regression
> that was introduced
On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx wrote:
> This PR fixes a regression introduced in #1723
>
> It reverts the changes made in the BorderPaneTest with new comments
> explaining why the values are what they are. It only fixes the regression
> that was introduced
On Tue, 22 Jul 2025 00:05:35 GMT, John Hendrikx wrote:
> This PR fixes a regression introduced in #1723
>
> It reverts the changes made in the BorderPaneTest with new comments
> explaining why the values are what they are. It only fixes the regression
> that was introduced
This PR fixes a regression introduced in #1723
It reverts the changes made in the BorderPaneTest with new comments explaining
why the values are what they are. It only fixes the regression that was
introduced, but it can be said that the calculation is probably also incorrect
when a vertical b
On Mon, 21 Jul 2025 17:17:38 GMT, Kevin Rushforth wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> There first needs to be a new bug filed. Once there is, and a f
On Sat, 14 Jun 2025 11:52:36 GMT, Marius Hanl wrote:
> I think wiping default style classes should not be done.
>
> Maybe somewhat related and only my understanding: There are quite some places
> in JavaFX Controls where e.g. a `StackPane` is used to somewhat mimic a
> `Control` (often a `Butt
On Tue, 15 Jul 2025 11:32:28 GMT, Johan Vos wrote:
> > The first question is: Does this have any use case beyond testing?
>
> Good question, and the answer is "Yes, absolutely". One of the main drivers
> for this was a project where PDF prints need to be generated server-side,
> starting from
On Tue, 15 Jul 2025 20:21:15 GMT, Martin Fox wrote:
> Another way to look at it: do we want to outlaw what ComboBox and Spinner are
> doing? It's not illegal to create a KeyEvent and fire it at a control. It's
> not illegal to consume a KeyEvent that originated in Glass. Things only fail
> whe
On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox wrote:
> The Mac platform code sends a KeyEvent into the scene graph and if the event
> is not consumed it gets sent on to the system menu. But ComboBox and Spinner
> always consume the original event and fire a copy which the system menu
> ignores.
On Mon, 14 Jul 2025 17:39:50 GMT, Martin Fox wrote:
> The Mac platform code sends a KeyEvent into the scene graph and if the event
> is not consumed it gets sent on to the system menu. But ComboBox and Spinner
> always consume the original event and fire a copy which the system menu
> ignores.
On Mon, 14 Jul 2025 18:46:53 GMT, Martin Fox wrote:
>>> > Does `resolveFocusDelegate` do what you need?
>>>
>>> Currently we turn on input method processing at the platform level if and
>>> only if there's any control in the focus chain that is set up to receive
>>> input method events and res
On Sun, 13 Jul 2025 21:34:42 GMT, Michael Strauß wrote:
> The record `com.sun.glass.ui.HeaderButtonMetrics` is used by Glass, but also
> in the FX layer (in `Stage` and `HeaderBar`). This is architectually unsound,
> as the FX layer should not directly reference the Glass implementation.
>
> T
On Fri, 11 Jul 2025 16:30:14 GMT, Martin Fox wrote:
> > Does `resolveFocusDelegate` do what you need?
>
> Currently we turn on input method processing at the platform level if and
> only if there's any control in the focus chain that is set up to receive
> input method events and respond to in
On Wed, 9 Jul 2025 17:21:06 GMT, Martin Fox wrote:
>> Implementation of [focus
>> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> modules/javafx.graphics/src/main/java/javafx/scene/Node.java line 8654:
>
>> 8652: * @since 26
>> 8653: */
>> 8654: No
On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strauß wrote:
> Implementation of [focus
> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
modules/javafx.graphics/src/main/java/com/sun/javafx/scene/DelegatingEventDispatcher.java
line 57:
> 55: retarget = true
On Tue, 8 Jul 2025 21:44:35 GMT, Michael Strauß wrote:
>> Implementation of [CSS media
>> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> document
On Sun, 9 Feb 2025 18:23:47 GMT, Michael Strauß wrote:
>>> @hjohn I think what's missing in your model is the option to have an
>>> independently focusable node inside of a control. For example, think of a
>>> Button placed within a Button (via its `graphic` property). Clicking the
>>> nested
On Tue, 11 Feb 2025 18:54:50 GMT, Martin Fox wrote:
> > I don't think the distinction quite holds. Scene does not delegate all key
> > events. Menu shortcuts for example are consumed and never dispatched, and I
> > think the same goes for mnemonics. Navigation keys are dispatched, and only
> >
On Sun, 9 Feb 2025 11:31:09 GMT, John Hendrikx wrote:
>>> @hjohn Could you provide an outline of the algorithm that a control would
>>> use to automatically determine the focus delegate? I really can't envision
>>> what that would look like. For that matte
On Sat, 8 Feb 2025 10:35:00 GMT, John Hendrikx wrote:
>> This looks really good. I'm wondering if this could be simplified further.
>> Specifically, I think the `hoistFocus` flag and manual management of the
>> focus delegate may not be needed.
>>
>>
On Fri, 3 Jan 2025 10:36:23 GMT, John Hendrikx wrote:
>> Implementation of [focus
>> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
>
> This looks really good. I'm wondering if this could be simplified further.
> Specifically, I think
On Sat, 9 Nov 2024 01:28:53 GMT, Michael Strauß wrote:
> Implementation of [focus
> delegation](https://gist.github.com/mstr2/44d94f0bd5b5c030e26a47103063aa29).
This looks really good. I'm wondering if this could be simplified further.
Specifically, I think the `hoistFocus` flag and manual m
On Mon, 17 Feb 2025 01:15:37 GMT, John Hendrikx wrote:
> 8350917: Allow parent nodes to provide CSS styleable properties for child
> nodes
This would also address https://bugs.openjdk.org/browse/JDK-8092347
-
PR Comment: https://git.openjdk.org/jfx/pull/1714#issuec
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and th
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and th
On Fri, 28 Feb 2025 21:30:31 GMT, John Hendrikx wrote:
>> Fixes the case where `VBox` will ignore the (horizontal) bias of a child
>> when its fill width property is set to `false`. This manifests itself with
>> labels that have their wrap text property set to `true`, and th
On Sat, 5 Jul 2025 02:32:18 GMT, Glavo wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Clarify terms
>
> Unfortunately, this commit caused our app to behave abnormally :(
>
&g
;
>
> -andy
>
>
>
>
>
> *From: *openjfx-dev on behalf of John
> Hendrikx
> *Date: *Friday, June 27, 2025 at 03:15
> *To: *openjfx-dev@openjdk.org
> *Subject: *Proposal: Exposing a GraphicsContext-like API for
> WritableImage via Software Renderer
>
Hi Cormac,
That definitely looks like a bug. Setting the maximum constraint should
not have that effect. The documentation describes what you'd expect and
does not allude to the odd side effects you are seeing.
Some work was done recently on the resizing of table columns, perhaps a
regression w
On Thu, 13 Mar 2025 10:36:40 GMT, John Hendrikx wrote:
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
This pull request has now been integrated
On Fri, 27 Jun 2025 15:14:23 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Also repaint when going to maximized
>
> modules/javafx.graphics/src/main/
Hi list,
I'm exploring whether there is interest in exposing a (Canvas)
GraphicsContext-like interface for WritableImage backed by the existing
software rendering pipeline. Currently, JavaFX offers two main
choices for drawing and pixel manipulation, each with different trade-offs:
- Canvas prov
I've looked at the code as well, and I think I agree with your
assessment. `getChildTransformedBounds` does a lot of stuff, and will
modify properties that can be observed while the `dirtyChildren` list is
being used in `updateCachedBounds`.
However, what I think the problem is directly with th
Hi,
The possibility for code being called re-entrantly on the same thread is
unfortunately something that slips the minds of developers quite easily
when they develop single threaded code. Developers assume that their
private fields will be in a consistent state because code being executed
will al
I've been doing some Canvas work to implement a simple image editing
system, and I noticed that some things are quite hard to do due to a
lack of certain blend modes.
1) Given an empty fully transparent Canvas, you can easily draw opaque
ovals onto it (using a circular brush) but cannot use `fillO
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
John Hendrikx has updated the pull request incrementally with one additional
commit since the l
On Wed, 18 Jun 2025 20:32:37 GMT, Martin Fox wrote:
> > I have noticed the tests for maximized stages fail on my system:
>
> That's expected. This PR fixes the case where the window goes from iconified
> to restored. When looking at the code I realized the same fix needs to be
> applied when t
On Wed, 18 Jun 2025 09:04:32 GMT, Ambarish Rapte wrote:
> A simple change to remove `@Test` annotation from two graphics unit tests.
>
> The two tests have 2 test annotations `@Test` and `@RepeatedTest`, It results
> in warning message.
>
>
> WARNING: Possible configuration error: method [pub
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
John Hendrikx has updated the pull request incrementally with two additional
commits since the l
> Adds code to trigger a scene update when a Window is restored
>
> This seems to solve https://bugs.openjdk.org/browse/JDK-8351867 and
> https://bugs.openjdk.org/browse/JDK-8146479
John Hendrikx has updated the pull request with a new target base due to a
merge or a rebase. The
2-bit VM or one that is using
> compressed oops.
>
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|2
2-bit VM or one that is using
> compressed oops.
>
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|20 bytes ove
2-bit VM or one that is using
> compressed oops.
>
> |Listener|ExpressionHelper|ListenerManager|OldValueCaching ListenerManager|
> |---|---|---|---|
> |No Listeners|none|none|none|
> |Single InvalidationListener|16 bytes overhead|none|none|
> |Single ChangeListener|2
On Sat, 7 Jun 2025 23:56:38 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Sat, 7 Jun 2025 20:59:29 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Sat, 7 Jun 2025 20:55:47 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Sat, 7 Jun 2025 20:12:10 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Sat, 7 Jun 2025 20:44:04 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Sat, 7 Jun 2025 20:05:51 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Thu, 13 Mar 2025 03:31:13 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Change StackOverflowException to warning log
>> - Support keeping last message
On Tue, 3 Jun 2025 01:14:04 GMT, Michael Strauß wrote:
> Some `` tags in cssref.html are written as `` or ``. It should
> be ``, since it is a void element.
>
> A single reviewer is sufficient.
Marked as reviewed by jhendrikx (Reviewer).
-
PR Review: https://git.openjdk.org/jfx/p
On Sun, 1 Jun 2025 21:42:17 GMT, Michael Strauß wrote:
> `EventHandler` property implementations in `Scene` and `Window` use anonymous
> classes derived from `ObjectPropertyBase`. We can remove about 650 lines of
> boilerplate code by using a common property class instead.
I think this is a hu
On Tue, 3 Jun 2025 16:32:21 GMT, Michael Strauß wrote:
> I've tried to do something similar for controls by replacing a lot of the
> anonymous classes with concrete ones. I can't find the issue/discussion right
> now, but Kevin measured a non-negligible increase in memory usage. I assume
> it'
On Thu, 29 May 2025 15:47:20 GMT, Michael Strauß wrote:
>> Implementation of [CSS media
>> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> reorder
On 29/05/2025 18:23, Dirk Lemmermann wrote:
> Hi everyone,
>
> Is there any chance we can get font weight working properly so that I can use
> a font with medium boldness and use it by declaring: -fx-font-weight: bolder;
> or by declaring -fx-font-weight: 600;? I know I can work around it by usi
On Mon, 19 May 2025 07:06:38 GMT, Lukasz Kostyra wrote:
>> This follow-up change finishes the earlier changes to
>> `ImageStorage.loadAll()` and adds support for loading specific scale
>> requested in the input.
>>
>> `loadAll()` will now first check if the input path ends with a scaling level
On Fri, 16 May 2025 07:03:38 GMT, Lukasz Kostyra wrote:
>> This follow-up change finishes the earlier changes to
>> `ImageStorage.loadAll()` and adds support for loading specific scale
>> requested in the input.
>>
>> `loadAll()` will now first check if the input path ends with a scaling level
On Thu, 15 May 2025 20:10:53 GMT, John Hendrikx wrote:
>> This follow-up change finishes the earlier changes to
>> `ImageStorage.loadAll()` and adds support for loading specific scale
>> requested in the input.
>>
>> `loadAll()` will now first check if the input
On Thu, 15 May 2025 20:34:21 GMT, Michael Strauß wrote:
>> Are you sure a delay is a good way to solve this? It won't guarantee that
>> no inconsistent states will be observed (what if Windows is slower, or a
>> change is reverted within the delay period -- you may still see "half"
>> changes
On Thu, 15 May 2025 19:16:03 GMT, Michael Strauß wrote:
> I am not comfortable with this change, as it falls under application
> requirements.
>
> The function of the JavaFX platform is to communicate the OS events as
> faithfully as it can, in my opinion
The function of JavaFX is to abstract
On Thu, 15 May 2025 18:50:20 GMT, Michael Strauß wrote:
>> If it takes that long to update all the colors, maybe we should not add
>> complexity to this subsystem and just send the events as they come?
>>
>> What exactly is the problem the user experiences right now?
>
> A single user-facing se
On Thu, 15 May 2025 11:27:21 GMT, Lukasz Kostyra wrote:
> This follow-up change finishes the earlier changes to
> `ImageStorage.loadAll()` and adds support for loading specific scale
> requested in the input.
>
> `loadAll()` will now first check if the input path ends with a scaling level
> s
On Wed, 7 May 2025 13:06:50 GMT, Kevin Rushforth wrote:
>> `NullCoalescingPropertyBase` (used in `ScenePreferences`) is initially
>> disconnected. It will set its initial value to the value is reads from
>> `PlatformPreferences`, but it will not subscribe to change notifications.
>> The reason
On Tue, 6 May 2025 07:03:06 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/docs/javafx/scene/doc-files/media-query.svg
>> line 2:
>>
>>> 1:
>>> 2: >
>> just an observation: these images look blurry on my mac external monitor
>> (scale=1) relative to the w3.org ones (on the le
On Thu, 24 Apr 2025 22:36:09 GMT, Andy Goryachev wrote:
> > The details button is private and not documented
>
> it is not private: the method that creates it in the DialogPane:817 is
> protected, so the application can override it and get a pointer to the
> button, set styles, etc.
>
> `prot
d loaded to get going.
--John
> On 25/04/2025 00:14, John Hendrikx wrote:
>>
>> On 24/04/2025 22:07, Christopher Schnick wrote:
>>>
>>> Hey John,
>>>
>>> Thanks for taking your time on going into the details here.
>>>
>>> About our
On Thu, 24 Apr 2025 14:50:22 GMT, Andy Goryachev wrote:
> > Then we can close this, as that's what the original code does already.
>
> Exactly (but I like the changes you made to add/remove "more"/"less" styles,
> since they won't erase any styles that the application might add during
> constr
ork
involved however is fairly trivial and could be done before or after the
PR mentioned is integrated.
--John
>
> Best
> Christopher Schnick
>
> On 24/04/2025 03:56, John Hendrikx wrote:
>>
>> Hi,
>>
>> I don't think adding synchronized in E
On 23/04/2025 20:59, Andy Goryachev wrote:
>
> Even though JavaFX explicitly permits creating Nodes and Scenes in a
> thread other than the Application Thread, I think it is still a bad
> idea, and I would strongly suggest against doing so. The code might
> work - initially - but you will soon dis
In both cases only a partial fix can be applied that can ensure that at
a minimum the listener management doesn't get into a bad state. The
issue of what happens when a callback occurs on a second thread while
instances are being manipulated on the first thread will remain.
The partial fix would
Hi,
I don't think adding synchronized in ExpressionHelper is going to really
solve your problem. It will just move it elsewhere, but feel free to
let me know your exact scenario. For now I will make some assumptions.
I'm assuming you are constructing UI's in a background thread, and this
UI req
On Fri, 18 Apr 2025 14:39:41 GMT, Andy Goryachev wrote:
> > So... you want me to add more styles so it then ends up looking like a
> > correctly colored hyperlink?
>
> No. I would like to retain the existing functionality where the styles
> alternate between `[ "details-button", "less" ]` and
enjdk.org/browse/JDK-8089992
>
>
>
> -andy
>
>
>
>
>
> *From: *John Hendrikx
> *Date: *Wednesday, April 16, 2025 at 16:13
> *To: *Nir Lisker , Andy Goryachev
>
> *Cc: *openjfx-dev@openjdk.org
> *Subject: *[External] : Re: Unnecessary layouts; T
On Thu, 17 Apr 2025 15:58:28 GMT, Andy Goryachev wrote:
> I've added the Dialog page to the monkey tester
> https://github.com/andy-goryachev-oracle/MonkeyTest
>
> Looking at the stock behavior, I don't really see the problem. The
> .details-button should not _look_ a hyperlink (despite being
On Wed, 12 Mar 2025 01:28:49 GMT, Nir Lisker wrote:
> Finished the 2nd part of the implementation review. I didn't delve into the
> logic of the listener management, but it looks sane :)
>
> I'll review the tests as the final part.
@nlisker did you have time to look at the final part?
---
On Thu, 17 Apr 2025 21:19:09 GMT, Andy Goryachev wrote:
> > If you use a `Hyperlink` control, you also want the result to be hyperlinky
> > and inherit all the hyperlinky styles
>
> not necessarily, if you want all the functionality but different visuals.
>
> BTW, the circular button in the Di
On Thu, 17 Apr 2025 21:06:08 GMT, Andy Goryachev wrote:
>> I'll double check and will let you know tomorrow.
>>
>> A code search shows that these are only used in 5 classes: ButtonBar,
>> ButtonBarSkin, Dialog, DialogPane, Properties, so chances are it's a digital
>> fossil.
>
> I can confirm
>
> -andy
>
>
>
>
>
>
>
> *From: *openjfx-dev on behalf of
> John Hendrikx
> *Date: *Monday, April 14, 2025 at 08:56
> *To: *openjfx-dev@openjdk.org
> *Subject: *Unnecessary layouts; TLDR; new method "req
On Wed, 16 Apr 2025 08:51:36 GMT, John Hendrikx wrote:
> The "show details" hyperlink button in an alert dialog that has an expandable
> detail area wipes out its base style class by overwriting all styles. This
> means styling in modena.css that targets `.hyperlink` i
On Wed, 16 Apr 2025 18:43:01 GMT, Michael Strauß wrote:
>> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
>> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
>> apply the value before notifying the listeners.
>
> Michael Strauß has updated
On Wed, 16 Apr 2025 20:59:28 GMT, Andy Goryachev wrote:
> An SCCE would have been nice, to help with the review/testing.
>
> edit: alternatively, I'll add the (missing) Dialog/DialogPane page to the
> monkey tester. 🐒🔬
If you still need one, I can provide a bit of code. It basically is just
On Wed, 16 Apr 2025 10:31:50 GMT, Michael Strauß wrote:
> A listener that is added to `Parent.needsLayoutProperty()` may see a wrong
> value when calling `Parent.isNeedsLayout()` from the callback. The fix is to
> apply the value before notifying the listeners.
Looks good to me. I didn't see
On Wed, 16 Apr 2025 10:10:36 GMT, Ambarish Rapte wrote:
>> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
>> property getter returns the wrapper itself, but what it should be doing is
>> return the read-only getter instead.
>>
>> A single reviewer should be sufficient
On Wed, 16 Apr 2025 08:59:55 GMT, Michael Strauß wrote:
> `Parent.needsLayout` is implemented with a `ReadOnlyBooleanWrapper`. The
> property getter returns the wrapper itself, but what it should be doing is
> return the read-only getter instead.
>
> A single reviewer should be sufficient.
Ma
On Tue, 15 Apr 2025 17:18:48 GMT, Thiago Milczarek Sayao
wrote:
>> If it's a bug, could you please create a JBS ticket?
>
> Sure. I'll look into it.
To be honest, I don't understand why we specify this at all. "white" surely
won't be the default when running on dark theme... I'm pretty sure o
The "show details" hyperlink button in an alert dialog that has an expandable
detail area wipes out its base style class by overwriting all styles. This
means styling in modena.css that targets `.hyperlink` is no longer applied,
like the default text fill colors.
The culprit is this code in Dia
I've been writing a container that does layout, and I've been using it
extensively in my latest project.
I noticed that many skins and controls will call requestLayout(), not
realizing that this will mark the current node + all parent nodes with
`NEEDS_LAYOUT`. This causes all those containers to
On Sun, 13 Apr 2025 15:24:43 GMT, Thiago Milczarek Sayao
wrote:
> Improve StageStyle Documentation
>
> - Update `StageStyle.UTILITY`:
> Clarified that UTILITY stages may impose platform-specific restrictions on
> window states, such as preventing maximize, minimize (iconify), and
> fullscreen
On Sun, 13 Apr 2025 17:34:15 GMT, Michael Strauß wrote:
>> Implementation of [CSS media
>> queries](https://gist.github.com/mstr2/cbb93bff03e073ec0c32aac317b22de7).
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> improve
On Sat, 12 Apr 2025 20:01:44 GMT, Michael Strauß wrote:
> By the way, can I interest you in a review of this PR?
Yes, I already partially checked it out, and was intending to do a closer
review soon.
-
PR Comment: https://git.openjdk.org/jfx/pull/1655#issuecomment-2799045186
On Fri, 11 Apr 2025 22:57:51 GMT, Andy Goryachev wrote:
> > You seem to be arguing against media queries themselves
>
> Probably. I am afraid the CSS subsystem will grow into a monster (I mean, it
> already is).
>
> The follow up question is what you guys think about updating `modena.css` to
Hi Thiago,
I ran this on Windows. My monitor setup is:
Left: 3840x2160 (150%) -- top left coordinate (-2560, 0) (-2560 because
of scaling)
Middle: 3840x2160 (150%) -- this one has a top left coordinate of (0, 0)
Right: 1920x1200 (100%) -- this one has a top left coordinate of (2560, 0)
When sta
1 - 100 of 1519 matches
Mail list logo
