er the correct navigation action
> themselves (for which as of this writing there is no public API).
>
> The same goes for all the other keys captured by `ScrollPane` when it does
> not have focus, although not as critical as the UP/DOWN/LEFT/RIGHT keys.
John Hendrikx has updated th
On Thu, 3 Oct 2024 15:55:55 GMT, Andy Goryachev 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 Thu, 3 Oct 2024 16:33:12 GMT, Andy Goryachev wrote:
> > or perhaps indeed something with traversal policies would need to be
> > created by the user to solve this on a case by case basis. It will be hard
> > to always do the expected thing with a control as generic as ScrollPane.
>
> I play
On Wed, 2 Oct 2024 21:12:07 GMT, Andy Goryachev wrote:
> I played a bit more with your example. Your CustomButtonSkin is weird as it
> does not place the original button in the scene graph, not sure if that's
> important.
I think there is a misunderstanding. The `CustomButton` **is** part of
On Wed, 2 Oct 2024 21:00:55 GMT, Martin Fox wrote:
> > > Focus either lies on the node that owns the ScrollPane (like a TableView)
> > > or one of the nodes inside the ScrollPane but not on the ScrollPane
> > > itself.
> >
> >
> > this seems to be incorrect: unless you set `mouseTransparent`,
On Wed, 2 Oct 2024 18:12:35 GMT, Martin Fox wrote:
> I agree that the current ScrollPane implementation is wrong. Traversal is an
> accessibility issue so it’s imperative that we don’t block the traversal
> keys. We can’t expect custom controls to work around the ScrollPane's faulty
> behavior
On Tue, 1 Oct 2024 19:50:44 GMT, Andy Goryachev wrote:
> > Here is a minimal working example
>
> Very helpful, thank you.
>
> I would say the use of arrow keys to traverse focus in this case _looks to
> me_ to be application-specific. In other words, this may or may not be the
> desired behav
On Mon, 30 Sep 2024 15:31:52 GMT, Andy Goryachev wrote:
> SCCE = Self-contained code example, or "complete code sample" in
> https://wiki.openjdk.org/display/OpenJFX/Submitting+a+Bug+Report
Ah, thank you, I hadn't seen this before.
> I am not entirely convinced that the proposed solution addre
On Mon, 30 Sep 2024 16:27:50 GMT, Andy Goryachev wrote:
> I do not see much behavioral difference between controls inside a regular
> VBox and VBox inside a ScrollPane
>
> https://github.com/andy-goryachev-oracle/Test/blob/main/src/goryachev/research/FocusPolicyResearch.java
>
> Am I doing thi
On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>>
On Thu, 26 Sep 2024 21:17:55 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 keyboa
On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote:
> The standard across all platforms is:
>
> - A dead key followed by a composable character generates the composed
> character. For example, a circumflex dead key followed by an 'e' should
> generate 'ê'.
> - A dead key followed by a characte
On Thu, 26 Sep 2024 21:17:55 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 keyboa
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 bubble up i
On Thu, 26 Sep 2024 21:17:55 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 keyboa
For some reason mails on the openjfx-dev mailinglist coming from
mar...@martinfox.com are not coming through to me
I have the same problem.
It sometimes takes a while, and sometimes they never get through :/ It
may indeed by Gmail, as I use that as well for the mailinglist.
--John
On 26/09
On 24/09/2024 22:29, Martin Fox wrote:
This proposal should give some quick background on how traversal key
events are handled, specifically that controls should let the key
events bubble up to the Scene to invoke traversal. And if the
traversal keys are always going to be consumed by the Sce
n-FX controls that consume keys as
scroll events when the scrollpane/bar wasn't specifically focused. It
would be very annoying I think if they did.
--John
I hope it makes sense :)
Em qui., 19 de set. de 2024 às 12:38, John Hendrikx
escreveu:
I've been looking into how exac
places focus on
the next input field -- good old efficient input and finger action.
No unnecessary and inefficient hand movements.
My $.02 on this whole discussion in this and associated threads
regarding addressing the FX TraversalPolicy.
On Thu, Sep 19, 2024 at 8:39 AM John Hendrikx
wr
I've been looking into how exactly navigation keys are being used in FX,
and who is responsible for handling them:
- Controls can choose to install navigational keys directly in their
input map (using FocusTraversalInputMap::getFocusTraversalMappings)
- Controls can choose to do nothing and lea
uite. You made a lot of good comments that require some
thought and careful consideration, for which I simply had no spare CPU
cycles last week or this week. Sorry, will definitely respond in
detail early next week.
-andy
*From: *John Hendrikx
*Date: *Tuesday, September 17, 2024 at 23:05
k you
-andy
*From: *John Hendrikx
*Date: *Saturday, September 14, 2024 at 09:41
*To: *Andy Goryachev ,
openjfx-dev@openjdk.org
*Subject: *[External] : Re: Proposal: Focus Traversal API
Hi Andy,
First let me say that when it comes to designing an API, you really
need to take the time to thin
On Mon, 16 Sep 2024 23:49:48 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>>
ust
"copy" said code)
Public API: Maybe some methods in Node, or some kind of static helper.
6. CSS styleable properties
If we really want to give power to our users, and impress them with a
flexible focus traversal API, then make these properties styleable.
Benefit: allow users to p
On Sun, 8 Sep 2024 20:55:53 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
Hi Andy / List,
I've given this some thought first, without looking too much at the
proposal.
In my view, focus traversal should be implemented using events, and FX
should provide standard handling of these events controlled with
properties (potentially even CSS stylable for easy mass changi
On Sun, 14 Jan 2024 14:54:36 GMT, John Hendrikx wrote:
> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>
> This can be done with only a minor API break, as `SimpleSelector` and
> `CompoundSelector` were public before. However, these classes could not be
>
On Mon, 9 Sep 2024 06:23:02 GMT, John Hendrikx wrote:
> This PR removes the pausing logic from AbstractPrimaryTimer. The test that
> is using it wasn't actually testing anything in AbstractPrimaryTimer itself,
> and no other code needs this pausing code.
This pull reques
This PR removes the pausing logic from AbstractPrimaryTimer. The test that is
using it wasn't actually testing anything in AbstractPrimaryTimer itself, and
no other code needs this pausing code.
-
Commit messages:
- Remove unused code
Changes: https://git.openjdk.org/jfx/pull/155
On Tue, 3 Sep 2024 16:47:12 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reject CSS where compound selectors don't consist of simple selectors
>
> module
On Thu, 5 Sep 2024 20:55:37 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Tue, 3 Sep 2024 13:48:06 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/css/StyleableLongProperty.java
>> line 140:
>>
>>> 138: long diff = endValue - startValue;
>>> 139: long result = startValue + Math.round(progress * diff);
>>> 140:
On Tue, 3 Sep 2024 12:37:15 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Mon, 2 Sep 2024 16:24:33 GMT, Michael Strauß wrote:
> Yes, it's a sizable chunk of the specification:
> https://www.w3.org/TR/css-transitions-1/#starting
Thanks, somehow I had trouble finding it.
> The algorithm as prescribed by the specification is one of several algorithms
> that were co
On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Sun, 1 Sep 2024 12:31:06 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Tue, 13 Aug 2024 12:05:43 GMT, John Hendrikx wrote:
>> `SimpleSelector` was deprecated for removal (from the public javafx.css
>> package). Now that it is moved to the internal package, the deprecation on
>> that was also removed. The `SuppressWarnings` is therefor
On Mon, 2 Sep 2024 12:45:02 GMT, John Hendrikx wrote:
>> Moves `SimpleSelector` and `CompoundSelector` to internal packages.
>>
>> This can be done with only a minor API break, as `SimpleSelector` and
>> `CompoundSelector` were public before. However, th
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods,
> but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to
> expose package private fields in `Match` for use by `CompoundSelector`
> - No
ery frame.
AnimationTimers are invoked between frames, as long as the timestamp
corresponds to the v-sync signal. (Well, unless the timer callback
measures its own time, which it shouldn't do.)
On Thu, Aug 29, 2024 at 8:20 PM John Hendrikx wrote:
I think they're a bit separate. Eve
It shouldn't matter when
AnimationTimers are invoked between frames, as long as the timestamp
corresponds to the v-sync signal. (Well, unless the timer callback
measures its own time, which it shouldn't do.)
On Thu, Aug 29, 2024 at 8:20 PM John Hendrikx
wrote:
>
> I think th
ystem timer in the presence of v-sync is
wrong, it simply can't work reliably. We get accurate frame
synchronization for free from Direct3D, we should use that instead of
system timers.
There's a JBS issue with a detailed analysis:
https://bugs.openjdk.org/browse/JDK-8136536
TLDR; AnimationTimer is being fed a time not based on the time the next
frame is expected to be rendered but the time of when the FX thread is
finally scheduled to do the callbacks. This time fluctuates wildly, and
is a time that's useless for doing frame accurate calculations of
animations (s
On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda wrote:
> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that
> make use of `FontConfigManager::getFontConfigFont`, which under certain
> cases, can return null.
>
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Andr
On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda wrote:
> This PR adds a couple of null checks to `LogicalFont` and `FTFactory`, that
> make use of `FontConfigManager::getFontConfigFont`, which under certain
> cases, can return null.
>
> I've tested this PR on both Linux (Ubuntu 22.04.4) and Andr
On Tue, 27 Aug 2024 15:50:54 GMT, Jose Pereda wrote:
> Shouldn't we fail gracefully after LogicalFont::getSlot0Resource if
> slot0FontResource is finally null?
It calls `PrismFontFactory::getDefaultFontResource` -- this function looks
practically everywhere to find some kind of font. I think
On 26/08/2024 22:42, Michael Strauß wrote:
can we create stylesheets programmatically without parsing (i.e. construct the
token tree directly)?
Maybe, but `Stylesheet` and its constituent classes really seem like
exposed implementation details of JavaFX. I would rather deprecate
their use and
The CSS code, and its API, to put it diplomatically, is IMHO a bit under
cooked.
I've had quite a few looks at it, and each time I've come to the
conclusion that it is near impossible to do any worthwhile improvements
to it without at a minimum getting rid of the ParsedValue abomination.
Thi
vents would probably be consolidated into a "permutation"
event.
In general, delayed notification scopes for properties could also be
very useful for application developers.
On Thu, Aug 22, 2024 at 9:59 AM John Hendrikx wrote:
I think I figured out the reason why this fails. The root ca
;
primaryStage.setScene(scene);
primaryStage.show();
}
--John
On 22/08/2024 09:37, John Hendrikx wrote:
I think I figured out the reason why this fails. The root cause lies
in a misconception I've seen in a lot of FX code.
JavaFX uses a single event thread model, which ensures all structures
rent is in a safe state.
The option I like the least is to introduce yet another instance flag
("processingListChange") and throwing an early exception if other code
is entered that doesn't expect it...
--John
On 22/08/2024 05:24, John Hendrikx wrote:
Hi List,
This is a bit
Hi List,
This is a bit of a long post. I'm mainly wondering if I did something
wrong that FX should detect early, or if I'm doing nothing unusual and
FX should handle the case described below correctly.
I encountered the bug where an NPE occurs in
Scene$ScenePulseListener#synchronizeNodes, a
On Tue, 13 Aug 2024 14:10:52 GMT, Nir Lisker wrote:
> > oops, yes, you did, my mistake. the master progressed since then, got me
> > confused.
> > I got a bunch of errors again after switching:
> > ```
> > Description ResourceTypePathLocation
> > Cannot infer type arguments for P
On Wed, 7 Aug 2024 22:31:57 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/CompoundSele
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods,
> but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to
> expose package private fields in `Match` for use by `CompoundSelector`
> - No
On Tue, 13 Aug 2024 12:05:18 GMT, John Hendrikx wrote:
>> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
>>
>>> 88: private final int specificity;
>>> 89:
>>> 90: @SuppressWarnings("removal")
>>
>>
On Tue, 13 Aug 2024 11:51:39 GMT, Nir Lisker wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug
>
> modules/javafx.graphics/src/main/java/javafx/css/Match.java line 90:
&
On Tue, 13 Aug 2024 11:54:16 GMT, Nir Lisker wrote:
> I see a lot of aversion from for-each loops in favor of indexed loops in the
> classes this PR touches. While I don't suggest to change it here, any idea
> why?
It's just the style the original code was written with. There is no reason to
On Sat, 10 Aug 2024 07:10:03 GMT, Loay Ghreeb wrote:
> Shift + Click again on Col2 to remove the sort from Col2. The order will stay
> the same [1, 0, 3, 2], but the expected order is [1, 0, 2, 3] as in step 2.
Why is that the expected order? It is "a" possible, but valid order. When
only so
On Sat, 10 Aug 2024 11:24:34 GMT, John Hendrikx wrote:
>> I also think that we're probably dealing with two different things that are
>> mixed up in `StyleConverter`. But instead of having this discussion here, it
>> probably makes more sense to have it in the cont
On Fri, 9 Aug 2024 22:36:03 GMT, Michael Strauß wrote:
>> Sorry to keep harping on this, but so far, I think all the options are quite
>> poor from the perspective of the user, and from a perspective of "could it
>> have been designed this way in the first place".
>>
>> I also think I smell s
On Fri, 9 Aug 2024 13:36:34 GMT, Michael Strauß wrote:
>> Clear, thanks MIchael. I would suggest `Reconstructable` as the name, which
>> seems more inline with interface naming (especially `Interpolatable`). Reads
>> nice also:
>>
>> if (converter instanceof Reconstructable r) { ... }
>
>
nd.
Em qua., 7 de ago. de 2024 às 15:55, John Hendrikx
escreveu:
For detecting long running tasks on the FX thread, there are some
other options which you can do as a user (but perhaps we can
support it directly within FX). I use this kind of code to detect
long running things o
cumulativeDurations.addLast(cumulativeDurations.removeLast() + totalTime);
returntimeSpentAtThisLevel;
}
}
--John
On 08/08/2024 12:47, Thiago Milczarek Sayão wrote:
Nice! I will steal it if you don't mind.
Em qua., 7 de ago. de 2024 às 15:55, John Hendrikx
escreveu:
For detecting lon
On Fri, 9 Aug 2024 03:30:09 GMT, Loay Ghreeb wrote:
>> Fix an issue in `SortedList` where the sorting became incorrect when adding
>> new items that are equal to existing items according to the comparator. The
>> `SortedList` should consider the insertion index of these items to maintain
>> th
On Thu, 8 Aug 2024 15:45:37 GMT, Andy Goryachev wrote:
>> Returning `null` seems fine from the perspective of `StyleConverter`, but it
>> makes the calling code very awkward. Remember, we ended up here because we
>> needed a way to detect whether an object would support component-wise
>> trans
On Wed, 7 Aug 2024 22:54:10 GMT, Andy Goryachev wrote:
>> I considered doing more here, but as this is all just moved code, I'm
>> hesitant to change it as part of this PR. For example, if there is a faulty
>> binary CSS file which has a negative value for the short, then the original
>> code
On Wed, 7 Aug 2024 22:27:10 GMT, Andy Goryachev wrote:
>> John Hendrikx has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix bug
>
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializ
On Wed, 7 Aug 2024 22:40:29 GMT, Andy Goryachev wrote:
> this PR has been out for too long, could you please merge the latest master
> branch in?
I did yesterday, or did something go wrong?
> modules/javafx.graphics/src/main/java/com/sun/javafx/css/BinarySerializer.java
> line 111:
>
>> 109:
ainty and does NOT give any indication of the cause (you see only
symptoms). Such bugs are the nastiest kind, and it is (IMHO) a failure
of a framework to not help you detect these as early as possible.
--John
I am curious what other members of community think of this issue.
-andy
*From: *Joh
On Wed, 7 Aug 2024 16:03:59 GMT, Andy Goryachev wrote:
>> Whether a style converter supports reconstruction should be a statement
>> about the type, not a statement about the instance. For this reason, I don't
>> prefer an instance method like `isSupportReconstruction()`. In any case,
>> these
e threaded by design. Yes, there might
be occasions when one can use multiple threads and it is sort of
allowed, but doing so may lead to unpleasant issues down the road, so
the question is why would you want to do that?
-andy
*From: *openjfx-dev on behalf of John
Hendrikx
*Date: *Sunday
On 8/4/2024 8:40 PM, quizynox wrote:
Hello,
Wouldn't it be better to implement this check in assert to avoid
any impact in production?
пн, 5 авг. 2024 г. в 03:30, John Hendrikx :
Hi list,
I know of quite some bugs and users that have been bitten by
Hey Michael,
Thanks, I totally forgotten about that post apparently, perhaps we can
make this work.
I thought of something else as well. We seem to be assuming that
checking the Thread is the expensive part, where it in reality is one of
the cheapest checks that we can do. We could always c
On Wed, 7 Aug 2024 15:12:22 GMT, Andy Goryachev wrote:
>>> would it be easier just to pass a boolean to the constructor? we are
>>> changing the public API anyway...
>>
>> Usually boolean parameters are not a good API choice, but I have no strong
>> opinion on this one. What do you prefer?
>
>
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods,
> but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to
> expose package private fields in `Match` for use by `CompoundSelector`
> - No
On Tue, 6 Aug 2024 22:43:48 GMT, Andy Goryachev wrote:
>> I can see if I can externalize this or if that would run into issues. Also
>> please note, although technically an API change, it is NOT an accessible API
>> (and so can be removed at any time) because only the permitted types can
>> a
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods,
> but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to
> expose package private fields in `Match` for use by `CompoundSelector`
> - N
> - `SimpleSelector` and `CompoundSelector` have a few more `public` methods,
> but they're internal now, so it is irrelevant
> - `createMatch` was implemented directly in `Selector` to avoid having to
> expose package private fields in `Match` for use by `CompoundSelector`
> - No
Hi list,
I know of quite some bugs and users that have been bitten by the
threading model used by JavaFX. Basically, anything directly or
indirectly linked to an active Scene must be accessed on the FX thread.
However, as FX also allows manipulating nodes and properties before
they're displ
On Mon, 15 Jul 2024 13:21:53 GMT, John Hendrikx wrote:
> Fixes an infinite loop that can occur while resolving lookups.
>
> There were 2 bugs:
> - A `contains` check was done on some value X, but then a value Y was added
> to the set used to track duplicates
> - The `Set` t
On Fri, 2 Aug 2024 17:51:00 GMT, Andy Goryachev wrote:
> re-tested on macOS, works as expected.
>
> also tested in the Monkey Tester with the CSS provided in the ticket (errors
> appear in stderr as expected), and after the offending CSS is removed (gets
> back to normal).
Thanks for the exte
On Sat, 3 Aug 2024 00:14:23 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line
>> 183:
>>
>>> 181: * If the intermediate list is shallow-equal to the first
>>> list passed into the method (i.e. its
>>> 182: * elements a
On Sun, 4 Aug 2024 19:08:14 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Sun, 4 Aug 2024 15:32:10 GMT, Michael Strauß wrote:
>> I've taken a closer look, and I have the feeling that
>> `ComponentTransitionable` is more of an indicator that the corresponding
>> `StyleConverter` has implemented `convertBack`. I think noting this
>> information closer to the sourc
On Sun, 4 Aug 2024 14:51:47 GMT, Michael Strauß wrote:
>> Sorry if this came across as a bit negative, it's not intended in that way.
>> I just think optimizing too early has far more drawbacks than it has
>> benefits. In part this is also a reflection on a lot of FX code; some code
>> is cle
On Sat, 3 Aug 2024 00:14:28 GMT, Michael Strauß wrote:
>> I see two uses of this interface, both in combination with `Interpolatable`.
>> Should this just extend `Interpolatable`, or are there cases to be expected
>> where this marker is present but `Interpolatable` is not?
>>
>> Also, have y
On Fri, 2 Aug 2024 01:32:09 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/Border.java line
>> 331:
>>
>>> 329:
>>> 330: for (int i = 0, max = strokes.size(); i < max; i++) {
>>> 331: final BorderStroke stroke = strokes.get(i);
>>
>
On Sat, 3 Aug 2024 11:43:12 GMT, John Hendrikx wrote:
>> There's no performance problem in the sense that my test application runs
>> slowly in any noticeble way. It's one more piece of trying to minimize the
>> allocation of objects in the very common case where no
On Sat, 3 Aug 2024 10:04:00 GMT, Michael Strauß wrote:
> Do you think it is preferrable to appeal to JIT magic instead of explicitly
> coding the behavior?
If the code leads to less questions and is more readable for it, and there is
no reason to optimize in the first place (ie. you didn't see
On Sat, 3 Aug 2024 00:14:20 GMT, Michael Strauß wrote:
>> modules/javafx.graphics/src/main/java/com/sun/javafx/util/Utils.java line
>> 197:
>>
>>> 195: if (secondList.isEmpty()) {
>>> 196: return firstList.isEmpty() ? firstList : secondList;
>>> 197: }
>>
>> This lo
On Fri, 2 Aug 2024 21:30:49 GMT, John Hendrikx wrote:
>> Michael Strauß has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - fix since tag
>> - adjust table styling
>
> modules/java
On Fri, 2 Aug 2024 01:39:11 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>> i
On Thu, 25 Jul 2024 14:54:46 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/test/java/test/javafx/scene/CssStyleHelperTest.java
>> line 699:
>>
>>> 697:
>>> 698: // Note: on Windows, the message is using inconsistent line
>>> endings (sometimes Windows, sometimes Linux)
>>
eaning
> that the caller (which may be processing multiple values in a loop) would end
> up with an empty set, losing track of what was visited so far
>
> Also removed a redundant `null` check (an NPE would have occurred before it
> could reach that code).
John Hendrikx has updat
eaning
> that the caller (which may be processing multiple values in a loop) would end
> up with an empty set, losing track of what was visited so far
>
> Also removed a redundant `null` check (an NPE would have occurred before it
> could reach that code).
John Hendrikx has up
On Thu, 25 Jul 2024 19:03:14 GMT, Andy Goryachev wrote:
> Fixed Eclipse .classpath in the systemTests-test project.
Marked as reviewed by jhendrikx (Reviewer).
-
PR Review: https://git.openjdk.org/jfx/pull/1516#pullrequestreview-2201629740
On Fri, 12 Jul 2024 10:25:57 GMT, John Hendrikx wrote:
> This change removes the origin determination from `resolveLookups`. Instead,
> the origin from the style is used.
>
> Although a comment in the code alluded that this may cause problem with
> `INLINE` styles, this
eaning
> that the caller (which may be processing multiple values in a loop) would end
> up with an empty set, losing track of what was visited so far
>
> Also removed a redundant `null` check (an NPE would have occurred before it
> could reach that code).
John Hendrikx has updat
1 - 100 of 1206 matches
Mail list logo
