On Mon, 22 Jul 2024 09:45:38 GMT, John Hendrikx wrote:
> Conversion of the CssStyleHelperTest to JUnit 5 for PR's #1503 and #1505
Marked as reviewed by mhanl (Committer).
-
PR Review: https://git.openjdk.org/jfx/pull/1515#pullrequestreview-2191270417
On Fri, 12 Jul 2024 15:14:47 GMT, Marius Hanl wrote:
> This pull request contains a backport of commit e3c15957 from the openjdk/jfx
> repository.
This pull request has now been integrated.
Changeset: e89443de
Author:Marius Hanl
URL:
https://git.openjdk.org/jfx/
This pull request contains a backport of commit e3c15957 from the openjdk/jfx
repository.
-
Commit messages:
- Backport e3c15957488256ec53c5fb9978e336c59b69d65e
Changes: https://git.openjdk.org/jfx/pull/1504/files
Webrev: https://webrevs.openjdk.org/?repo=jfx=1504=00
Issue:
On Thu, 11 Jul 2024 22:33:38 GMT, Marius Hanl wrote:
> Tests that the `Stage Size` is between the `Visual Screen bounds - 50
> (delta)` and `Screen bounds + 50 (delta)`.
> -> `stageSize >= (visualBounds - 50)` & `stageSize <= (bounds + 50)`.
>
> Tested only on Wi
On Fri, 8 Mar 2024 15:58:09 GMT, Marius Hanl wrote:
> This PR fixes a long standing issue where the `Tooltip` will always wait one
> second until it appears the very first time, even if the
> `-fx-show-delay` was set to another value.
>
> The culprit is, that the `
Tests that the `Stage Size` is between the `Visual Screen bounds - 50 (delta)`
and `Screen bounds + 50 (delta)`.
-> `stageSize >= (visualBounds - 50)` & `stageSize <= (bounds + 50)`.
Tested only on Windows 10 for now.
-
Commit messages:
- JDK-8336272: SizeToSceneTest: fullScreen
ity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happens at the low level (`NGNode`) side of JavaFX.
> ...
> I cou
On Thu, 11 Jul 2024 15:29:01 GMT, Kevin Rushforth wrote:
> If you can do it in the next 30 minutes, it will make JavaFX 23 before the
> RDP1 fork. If it is after the fork, it might be a candidate to backport to
> jfx23.
Damn, missed the time. I will keep it open until tomorrow, in case
On Thu, 11 Jul 2024 11:19:36 GMT, Kevin Rushforth wrote:
> With your latest change, the test now passes on my Windows 11 system. Maybe
> the resetting of `tooltipStartTime` and `tooltipShownTime` fixed it? I'll
> look more closely in a bit.
I would not expect that, but maybe it has something
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful and headless tests for the behaviour since ther
On Wed, 10 Jul 2024 23:12:32 GMT, Kevin Rushforth wrote:
> Have you run it on Windows?
Yes, on Windows 10 and Windows 11. Executed the test multiple time now again,
always around 110 - 140 ms for me. Weird.
-
PR Comment:
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful and headless tests for the behaviour since ther
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful and headless tests for the behaviour since ther
On Thu, 4 Jul 2024 09:32:39 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit
On Mon, 8 Jul 2024 17:49:10 GMT, Andy Goryachev wrote:
>> Thought about this well, didn't test yet
>
> see for example
> https://github.com/openjdk/jfx/blob/72701e6cb4095b8f5042f54ae6bb2c0cec446bcf/modules/javafx.graphics/src/test/java/test/javafx/scene/Node_transition_Test.java#L142
Ah, looks
On Tue, 9 Jul 2024 11:38:30 GMT, Kevin Rushforth wrote:
>> Another possibility is the code that measures the time it takes to show the
>> tooltip.
>>
>> The current code uses Util.waitForLatch(), L244 which was written for a
>> different use case and actually introduces a small measurement
On Fri, 5 Jul 2024 17:13:47 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add many more unit tests for Tooltip
>
> tests/system/src/test/java/test/robot/javafx/
On Fri, 5 Jul 2024 17:11:54 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add many more unit tests for Tooltip
>
> modules/javafx.controls/src/test/
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
On Wed, 26 Jun 2024 10:43:30 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit
On Mon, 26 Feb 2024 20:51:56 GMT, Marius Hanl wrote:
> This PR fixes the problem that maximizing/fullscreen a `Stage` or `Dialog` is
> broken when `sizeToScene()` was called before or after.
>
> The approach here is to ignore the `sizeToScene()` request when the `Stage`
> is m
On Mon, 1 Jul 2024 09:16:52 GMT, Prasanta Sadhukhan
wrote:
>> Adding, then removing, and then adding a JFXPanel to the same component in
>> the Swing scene graph leads to a NullPointerException in GlassScene because
>> the sceneState is null.
>> Removing JFXPanel calls JFXPanel.removeNotify
On Tue, 4 Apr 2023 15:22:48 GMT, John Hendrikx wrote:
> This provides and uses a new implementation of `ExpressionHelper`, called
> `ListenerManager` with improved semantics.
>
> # Behavior
>
> |Listener...|ExpressionHelper|ListenerManager|
> |---|---|---|
> |Invocation Order|In order they
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request incrementally
On Thu, 27 Jun 2024 10:38:42 GMT, Lukasz Kostyra wrote:
> Change looks good, but I'm still seeing failures on my macOS system (Sonoma
> 14.5, MacBook Pro M1 Max):
I'm confused, the screen height is reported as 1085? Looks like the width, but
I still would not expect a width like that. Thats
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
On Tue, 25 Jun 2024 23:13:01 GMT, Andy Goryachev wrote:
> question is - do we really need to expose this method (for custom popup
> windows, for example), or not?
I can not really see why this is needed, other than maybe to not copy any style
from the owner.
It is hard to guess a usecase, so
On Wed, 26 Jun 2024 06:33:43 GMT, Markus Mack wrote:
>> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick
>> mark layout code in subclasses) is called during `Chart` `Axis` layout when
>> needed.
>> Previously, it was only called when tick mark length or range was
On Tue, 25 Jun 2024 14:51:03 GMT, Andy Goryachev wrote:
>> Either here or in the new method I think. What is your opinion?
>
> I wasn't sure; I suppose you have it right.
>
> I would have added the new JBS ticket id since RT- prefix is no more, but it
> is ok as it is.
Changed to the JDK
On Sun, 26 May 2024 13:02:23 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
On Tue, 25 Jun 2024 21:46:25 GMT, Markus Mack wrote:
>> This PR ensures the `tickMarksUpdated()` method (overriden with minor tick
>> mark layout code in subclasses) is called during `Chart` `Axis` layout when
>> needed.
>> Previously, it was only called when tick mark length or range was
On Tue, 28 May 2024 16:53:39 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a test for changing the stylesheet and always process CSS for that
>> matter
&
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request incrementally
On Tue, 28 May 2024 16:51:11 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a test for changing the stylesheet and always process CSS for that
>> matter
&
On Tue, 28 May 2024 16:48:39 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add a test for changing the stylesheet and always process CSS for that
>> matter
>
On Fri, 31 May 2024 17:47:22 GMT, Andy Goryachev wrote:
> you are right: I see the focus rectangle jitter at 175% scale on win 11 (w/o
> the fix), so it must be a different issue. At this scale, it merely shows a
> thinner line, perhaps that's why I did not notice it earlier.
Yeah exactly, it
On Tue, 28 May 2024 14:32:01 GMT, Andy Goryachev wrote:
> I do not see the issue without the fix though (at the same resolution).
I can, the `TableView` is the root of the `Scene` in this case. Happens inside
a `StackPane` as well.
On Tue, 28 May 2024 21:44:36 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
On Tue, 28 May 2024 04:35:34 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
On Tue, 28 May 2024 04:48:32 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request incrementally
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request incrementally
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request incrementally
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
On Thu, 23 May 2024 21:51:55 GMT, Marius Hanl wrote:
> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not
> modify the layout of `VirtualFlow`.
>
> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`,
> which made many calcu
ity modification,
> the rendering goes another (probably faster) route with rendering the clip.
> That's why setting the `opacity` to `0.99` fixes the issue - another route
> will be used for the rendering.
> This happens at the low level (`NGNode`) side of JavaFX.
> ...
> I could
On Thu, 23 May 2024 22:30:29 GMT, Andy Goryachev wrote:
> with the latest monkey tester I see that updating the stylesheet does not
> update the showingDelay property immediately. When the tooltip gets shown, I
> see the following output from the change listener added to this property:
>
>
On Fri, 24 May 2024 16:59:20 GMT, Andy Goryachev wrote:
>> Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not
>> modify the layout of `VirtualFlow`.
>>
>> This PR fixes the glitching by removing the code in `NGNode.renderRectClip`,
>> which made many calculations
On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
On Mon, 11 Mar 2024 16:54:25 GMT, John Hendrikx wrote:
>> Improves performance of selector matching in the CSS subsystem. This is done
>> by using custom set implementation which are highly optimized for the most
>> common cases where the number of selectors is small (most commonly 1 or 2).
On Thu, 23 May 2024 22:02:41 GMT, Kevin Rushforth wrote:
> I'm reasonably sure there was a good reason for the code in NGNode doing what
> it did. This will need very careful review and testing before we would accept
> it.
100% agree.
Note that the code there is a shortcut for performance
On Thu, 23 May 2024 14:54:36 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
Alternative PR to https://github.com/openjdk/jfx/pull/1330 which does not
modify the layout of `VirtualFlow`.
This PR fixes the glitching by removing the code in `NGNode.renderRectClip`,
which made many calculations leading to floating point errors.
Interestingly I found out, that
hough the nested event loop code is the same as for
> Mac) (I would appreciate if someone can do this as I have no access to an iOS
> device)
> - [x] Adjust copyright
> - [x] Write Systemtest
> - [x] Document the new behaviour - in general, there should be more
>
ltipBehaviour`. So the very first `Tooltip` gets processed correctly,
> but after no `Tooltip` will be processed by CSS before showing, resulting in
> the set `-fx-show-delay` to not be applied immediately.
>
> Added a bunch of headful tests for the behaviour since there were none be
On Tue, 14 May 2024 18:42:47 GMT, Martin Fox wrote:
> On Linux leaveNestedEventLoop makes changes in glass that cannot be erased or
> undone (it calls gtk_main_quit which updates internal GTK state that we don’t
> have access to). In the end GTK will exit the loops in the correct order but
>
the Window Manager of the OS will be confused and you will get
> weird flickering or wrong Window buttons (e.g. on Windows, the 'Maximize'
> button still shows the 'Restore' Icon, while we already resized the `Stage`
> to not be maximized).
Marius Hanl has updated the pull request with a new
On Tue, 30 Apr 2024 23:20:59 GMT, Kevin Rushforth wrote:
> * I wanted to verify different orders of operation, so I wrote a (manual)
> test program
I'm retesting and writing tests right now and reproduced one usecase out of my
head that indeed 'fails' now.
Take the following code:
tLayoutX`
> - Content
> - vsb
> - hsb
> - corner
>
> ---
> - VirtualFlow
> - viewRect **(->NEW IN THIS PR<-)** -> `setClip` -> clipRect
> (clippedContainer size)
> - clippedContainer/clipView -> `setLayoutX` (when scrolling)
> - sh
hough the nested event loop code is the same as for
> Mac) (I would appreciate if someone can do this as I have no access to an iOS
> device)
> - [x] Adjust copyright
> - [x] Write Systemtest
> - [x] Document the new behaviour - in general, there should be more
> information what
On Fri, 8 Mar 2024 16:39:56 GMT, Marius Hanl wrote:
>> This seems like a reasonable fix and spec change. Have you tested the case
>> of calling sizeToScene before setting full-screen or maximzed? Since the
>> pending flag will still be set in that case, I want to m
On Mon, 6 May 2024 21:11:35 GMT, Martin Fox wrote:
> I'll look into the Linux failure. The core EventLoop code passes an object
> into the application's leaveNestedEventLoop and expects to see that object
> returned from the applications's matching enterNestedEventLoop call. On Mac
> and
On Thu, 11 Apr 2024 20:23:52 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Allow Tooltip to process the owner styles first so that also global
>> styleshe
On Sat, 16 Mar 2024 15:47:18 GMT, Marius Hanl wrote:
> This PR fixes the issue that the initial column autosizing is wrong under
> some circumstances.
> The following things will break the initial autosizing:
> - Bold Column text (that is where I initially found this problem)
>
On Wed, 10 Jan 2024 19:21:16 GMT, Marius Hanl wrote:
> This PR fixes the border glitch/gap as explained in both linked tickets.
>
> I noted that the `ScrollPane` control does not suffer from this problem,
> although the code is mostly the same as in `VirtualFlow`. The `ScrollPa
On Sat, 9 Mar 2024 10:27:21 GMT, Marius Hanl wrote:
>> This PR fixes a long standing issue where the `Tooltip` will always wait one
>> second until it appears the very first time, even if the
>> `-fx-show-delay` was set to another value.
>>
>> The culprit
On Tue, 2 Apr 2024 07:37:15 GMT, Robert Lichtenberger
wrote:
>> @effad Since you benchmarked this method in #1358, could you do that again
>> with this changes?
>
>> @effad Since you benchmarked this method in #1358, could you do that again
>> with this changes?
>
> Sorry for the late reply,
On Wed, 3 Apr 2024 19:54:20 GMT, Jose Pereda wrote:
>> This PR fixes the issue that after committing an edit on a
>> ListView/TreeView/TableView/TreeTableView control, the control might lose
>> the focus unexpectedly.
>>
>> For that, it refactors the
>>
On Wed, 3 Apr 2024 19:51:08 GMT, Jose Pereda wrote:
>> modules/javafx.controls/src/test/java/test/javafx/scene/control/TreeViewTest.java
>> line 2362:
>>
>>> 2360: assertTrue(treeView.isFocused());
>>> 2361:
>>> 2362: VirtualFlowTestUtils.BLOCK_STAGE_LOADER_DISPOSE = true;
>>
On Thu, 11 Jan 2024 12:17:11 GMT, Marius Hanl wrote:
>> As seen in the unit test of the PR, when we click on the area above/below
>> the scrollbar the position jumps - but the jump is now not always consistent.
>> In the current version on the last cell - the UI alway
On Thu, 28 Mar 2024 08:49:44 GMT, drmarmac wrote:
>> This PR removes potentially incorrect usages of Stream.peek().
>> The changed code should be covered by the tests that are already present.
>
> drmarmac has updated the pull request incrementally with two additional
> commits since the last
On Wed, 20 Mar 2024 10:55:56 GMT, Jose Pereda wrote:
> This PR fixes the issue that after committing an edit on a
> ListView/TreeView/TableView/TreeTableView control, the control might lose the
> focus unexpectedly.
>
> For that, it refactors the
>
On Wed, 27 Mar 2024 13:41:21 GMT, Nir Lisker wrote:
> That's still 2 iterations.
Yes, but one advantage here:
We currently do `final List removed = new
ArrayList<>(c.getRemovedSize());`,
where we allocate a list with a size, that is probably too big since we filter
the removed items.
So with
On Wed, 27 Mar 2024 13:51:46 GMT, Nir Lisker wrote:
>> drmarmac has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove outdated comment
>
> modules/javafx.controls/src/main/java/javafx/scene/control/MultipleSelectionModelBase.java
>
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
On Thu, 21 Mar 2024 22:06:42 GMT, Marius Hanl wrote:
> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings
> of the stub font implementation. As I don't want to clutter the PR with that,
> I decided to cherrypick the improvements I did to a new tick
On Wed, 20 Mar 2024 19:53:40 GMT, Marius Hanl wrote:
>> This PR fixes the issue that the initial column autosizing is wrong under
>> some circumstances.
>> The following things will break the initial autosizing:
>> - Bold Column text (that is where I initially found th
On Tue, 26 Mar 2024 20:53:17 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> improve (stub) font tests, fallback and documentation
>
> modules/javafx.graphics/src
will be calculated with a little bit more width (1px). Checkout
> the test as well for that
>
> Note: This only changes test setup, no 'production' code.
Marius Hanl has updated the pull request incrementally with one additional
commit since the last revision:
improve javadoc
-
C
On Wed, 27 Mar 2024 09:07:15 GMT, drmarmac wrote:
>> modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java
>> line 176:
>>
>>> 174: .distinct()
>>> 175: .filter(removeRowFilter)
>>> 176: .forEach(row -> {
>>
>>
On Tue, 26 Mar 2024 16:32:41 GMT, Kevin Rushforth wrote:
> static imports (sorted alphabetically)
> one blank line
> ordinary imports (sorted alphabetically)
>
> No wildcard imports (I favor an exception for static imports).
+1 for something like this. It is a simple rule and pretty sure that
On Tue, 26 Mar 2024 20:36:02 GMT, Andy Goryachev wrote:
>> I can also use `round` here. Seems to be a bit safer, I agree.
>
> thank you.
>
> one more question - is it possible to set fractional scale with the
> StubToolkit, and how would that work in the StubFontLoader? Does it mean
> we'll
On Mon, 25 Mar 2024 23:00:25 GMT, Marius Hanl wrote:
>> modules/javafx.graphics/src/test/java/test/com/sun/javafx/pgstub/StubFontLoader.java
>> line 76:
>>
>>> 74: FontHelper.setNativeFont(font, nativeFont,
>>> font.getName
On Tue, 26 Mar 2024 20:40:11 GMT, Andy Goryachev wrote:
> If I write a test that uses the StubToolkit, one that requires some kind of
> font metrics - would that work? Will I get some kind of semi-valid values for
> preferred width of a text (Text, Labeled, etc.), or I cannot really rely on
>
bit more width (1px). Checkout
> the test as well for that
>
> Note: This only changes test setup, no 'production' code.
Marius Hanl has updated the pull request incrementally with one additional
commit since the last revision:
improve (stub) font tests, fallback and documentation
-
On Mon, 25 Mar 2024 23:11:12 GMT, Andy Goryachev wrote:
>> AFAIK, we do not have other tests with that problem.
>> I tried to keep the diff small, but nothing against writing a better method
>> to compare the points here with a delta.
>
> I am not sure why this is needed here, so my concern
On Fri, 22 Mar 2024 22:32:25 GMT, Andy Goryachev wrote:
>> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings
>> of the stub font implementation. As I don't want to clutter the PR with
>> that, I decided to cherrypick the improvements I did to a new ticket and PR.
>>
On Fri, 22 Mar 2024 22:59:34 GMT, Andy Goryachev wrote:
>> Marius Hanl has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - JDK-8186188: copyright
>> - JDK-8186188: fix tests
>
> modules/javafx.cont
On Fri, 22 Mar 2024 22:37:09 GMT, Andy Goryachev wrote:
>> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings
>> of the stub font implementation. As I don't want to clutter the PR with
>> that, I decided to cherrypick the improvements I did to a new ticket and PR.
>>
On Fri, 22 Mar 2024 22:29:32 GMT, Andy Goryachev wrote:
>> In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings
>> of the stub font implementation. As I don't want to clutter the PR with
>> that, I decided to cherrypick the improvements I did to a new ticket and PR.
>>
On Thu, 21 Mar 2024 18:47:24 GMT, Andy Goryachev wrote:
> Using Eclipse IDE to remove unused imports in javafx.controls and update the
> copyright year to 2024. Using wildcard for more than 10 static imports.
>
> This is a trivial change, 1 reviewer is probably enough.
Sure.
I may also need
In https://github.com/openjdk/jfx/pull/1405, I identified some shortcomings of
the stub font implementation. As I don't want to clutter the PR with that, I
decided to cherrypick the improvements I did to a new ticket and PR.
The current implementation has the following shortcomings:
- It does
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
On Tue, 19 Mar 2024 15:18:09 GMT, Andy Goryachev wrote:
> - PrismTextLayout:325 misspelled 'sliptCaretOffset'
> - DatePicker System.err.println L 125, 139, 172, 256
> - SpinnerTest.java L 1588, 1609 -> loses/losing (also in MenuBarSkin,
> DatePickerTest, FocusTest, and a few more)
> -
d after we triggered the
> autosize, which is what we would expect here since we measure text.
>
> I also copied the `TableColumnHeaderTest` and rewrote the tests for
> `TreeTableView` as well, so we can catch any errors here as well since they
> both use different code (although it
1 - 100 of 480 matches
Mail list logo
