Re: RFR: 8271054: [REDO] Wrong stage gets focused after modal stage creation [v7]
On Sat, 11 Dec 2021 00:32:06 GMT, Kevin Rushforth wrote: >> Thiago Milczarek Sayao has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Minimize changes > > On my Ubuntu 20.04 VM the bug still happens about 1/2 the time with this fix. @kevinrushforth can you try this lastest version, please? - PR: https://git.openjdk.java.net/jfx/pull/598
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v3]
On Mon, 7 Feb 2022 18:46:55 GMT, Jose Pereda wrote: >> This PR adds a predicate to TableView and TreeTableView selection models >> order to remove rows from the selection only when there are no selected >> cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with >> it. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Address feedback from reviewer Marked as reviewed by mstrauss (Author). - PR: https://git.openjdk.java.net/jfx/pull/709
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v3]
> This PR adds a predicate to TableView and TreeTableView selection models > order to remove rows from the selection only when there are no selected cells > in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback from reviewer - Changes: - all: https://git.openjdk.java.net/jfx/pull/709/files - new: https://git.openjdk.java.net/jfx/pull/709/files/fe943d4b..8e96bb3d Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=709=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=709=01-02 Stats: 9 lines in 3 files changed: 1 ins; 0 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/709/head:pull/709 PR: https://git.openjdk.java.net/jfx/pull/709
Re: [jfx18] RFR: 8271085: TabPane: Redundant API docs
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote:
> This is a Javadoc cleanup and correction fix for the TabPane as described in
> the JBS.
>
> Changes done for all the Properties of the TabPane -
> - Moved the property description to be over the property field.
> - Removed the unnecessary docs on property setter/getter and Property method.
Moving the test to the property field and removing it from the methods looks
good. I added some suggestions to touch up the docs a bit and correct some
mistakes.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
174:
> 172: /**
> 173: * Sets the model used for tab selection. By changing the model
> you can alter
> 174: * how the tabs are selected and which tabs are first or last.
This description is phrased like it's a setter. Probably
The selection model used for selecting tabs. Changing the model alters
how the tabs are selected and which tabs are first or last.
(there's no need to the `` either)
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
188:
> 186: * the TabPane will immediately update the location of the tabs to
> reflect
> 187: * this.
> 188: * The default position for the tabs is {@code Side.Top}.
I would rephrase a bit:
The position of the tabs in the {@code TabPane}. Changes to the value of this
property
immediately update the location of the tabs.
@defaultValue {@code Side.Top}
The 2nd sentence seems redundant anyway and I suggest to remove it. Unless
otherwise specified, all value changes are applied immediately (only
`Animation` properties come to mind that specify that the animation has to be
stopped for the changes to take effect).
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
244:
> 242: * Refer to the {@link TabClosingPolicy} enumeration for further
> details.
> 243: *
> 244: * The default closing policy is TabClosingPolicy.SELECTED_TAB
* The default value should be in an `@defaultValue` annotation.
* Missing `{@code }`s
* The line "Refer to the {@link TabClosingPolicy}" is redundant I think since
it's linked in the signature/definition, and if we want to keep it then an
`@see` might be preferable.
* "end-user's" (missing apostrophe)
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
270:
> 268: * the graphic isn't rotated, resulting in it always appearing
> upright. If
> 269: * rotateGraphic is set to {@code true}, the graphic will rotate
> such that it
> 270: * rotates with the tab text.
* Missing `@code`s
* I would rephrase the 2nd paragraph to be simpler:
```
If the value is {@code false}, the graphic isn't rotated, resulting in it
always appearing upright.
If it is {@code true}, the graphic is rotate with the tab text.
```
* `@defaultValue {@code false}`
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
295:
> 293: *
> 294: * This value can also be set via CSS using {@code
> -fx-tab-min-width}.
> 295: *
I would write
The minimum width of a tab in the TabPane. This can be used to limit
the length of text in tabs to prevent truncation. Setting the same minimum
and maximum widths will fix the width of the tab.
It makes it clear that it applies to each tab individually (and not the total
width of the tabs). The same applies for the other min/max height/width
properties.
The sentence "By default the min equals to the max." seems wrong. The
`DEFAULT_TAB_MIN_WIDTH` constant is set to 0. It should also be in a
`@defaultValue`.
The CSS mention is good, bit I never saw it mentioned for properties before.
Makes me wonder if we should add the CSS property as part of a property's
description in general via the automated javadoc tool.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
337:
> 335: *
> 336: * This value can also be set via CSS using {@code
> -fx-tab-max-width}.
> 337: *
* "By default the min equals to the max." The default is `Double.MAX_VALUE`.
* Comma before "the text will be truncated".
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
378:
> 376: *
> 377: * This value can also be set via CSS using {@code
> -fx-tab-min-height}.
> 378: *
Same comments as for the width properties.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
419:
> 417: *
> 418: * This value can also be set via CSS using {@code
> -fx-tab-max-height}.
> 419: *
Same comments as for the width properties.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
779:
> 777: * The drag policy for the tabs. The policy can be changed
> dynamically.
> 778: *
> 779: * @defaultValue TabDragPolicy.FIXED
I think that the 2nd sentence is redundant again. I would add an explanation
like "Specifies if tabs can be reordered or
Re: RFR: 8187309: TreeCell must not change tree's data
On Wed, 2 Feb 2022 14:18:18 GMT, Jeanette Winzenburg wrote: > Issue was TreeView commit editing implementation violated the spec'ed > mechanism: > > - no default commit handler on TreeView > - TreeCell modifying the data directly > > Fix is to move the saving of the edited value from cell into a default commit > handler in tree and set that handler in the constructor. > > Added tests that failed/passed before/after the fix (along with a sanity test > for default commit that passed also before). Also fixed a test bug (incorrect > registration of custom commit handler, see > [JDK-8280951)](https://bugs.openjdk.java.net/browse/JDK-8280951) in > TreeViewTest.test_rt_29650 to keep it passing. Looks good to me. - Marked as reviewed by mstrauss (Author). PR: https://git.openjdk.java.net/jfx/pull/724
Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]
On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path >> clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement >> fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix >> in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, >> reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot >> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized >> MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS >> 19.05 with many variants, improving almost-sorted datasets. We are >> collaborating to provide a complete Sort framework (15 algorithms, many >> various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourgès has updated the pull request incrementally with one > additional commit since the last revision: > > added test for huge polygon coords Thank you for confirming. - PR: https://git.openjdk.java.net/jfx/pull/674
Integrated: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs
On Mon, 22 Nov 2021 17:52:06 GMT, Michael Strauß wrote:
> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype
> specified for images encoded in data URIs. This should be improved as follows:
>
> 1. If the specified image subtype is not supported, an exception will be
> thrown.
> 2. If the specified image subtype is supported, but the data contained in the
> URI is of a different (but also supported) image format, the image will be
> loaded and a warning will be logged. For example, if the MIME type is
> "image/jpeg", but the image data is PNG, the following warning will be
> generated:
>
>
> Image format 'PNG' does not match MIME type 'image/jpeg' in URI
> 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC'
>
>
> Also, the javadoc of `javafx.scene.image.Image` incorrectly states:
>
> 94* If a URL uses the "data" scheme, the data must be base64-encoded
> 95* and the MIME type must either be empty or a subtype of the
> 96* {@code image} type.
>
> However, omitting the MIME type of a data URI is specified to imply
> "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI`
> class is implemented according to this specification, trying to load an image
> without MIME type correctly fails with an `ImageStorageException`:
> "Unexpected MIME type: text".
>
> The solution is to fix the documentation:
>
> 94* If a URL uses the "data" scheme, the data must be base64-encoded
> - 95* and the MIME type must either be empty or a subtype of the
> - 96* {@code image} type.
> + 95* and the MIME type must be a subtype of the {@code image} type.
> + 96* The MIME type must match the image format of the data contained
> in
> + 97* the URL. In case of a mismatch between MIME type and image
> format,
> + 98* the image will be loaded if the image format can be determined
> by
> + 99* JavaFX, and a warning will be logged.
This pull request has now been integrated.
Changeset: f326e78f
Author:Michael Strauß
Committer: Kevin Rushforth
URL:
https://git.openjdk.java.net/jfx/commit/f326e78ffdfcbbc9085bc50a38e0b4454b757157
Stats: 266 lines in 16 files changed: 170 ins; 8 del; 88 mod
8277572: ImageStorage should correctly handle MIME types for images encoded in
data URIs
Reviewed-by: kcr, arapte
-
PR: https://git.openjdk.java.net/jfx/pull/676
Re: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6]
On Mon, 7 Feb 2022 15:03:07 GMT, yosbits wrote:
> At least the following method do not need to remove the static modifier, but
> they do. Is there any benefit?
>
> ```java
> public int getNumBands(ImageType type) {
> ```
I think the fact that the method doesn't access any instance fields is an
arbitrary implementation detail. Making the method non-static aligns its usage
with all other methods, which can only be called on a instance reference.
-
PR: https://git.openjdk.java.net/jfx/pull/676
Re: RFR: 8274066: Polygon filled outside its area when very large coordinates are used [v2]
On Mon, 10 Jan 2022 00:04:00 GMT, Laurent Bourgès wrote: >> Changelog for this MarlinFX 0.9.4.5 release: >> >> The Marlin-renderer 0.9.4.5 release provides bug fixes on Marlin's path >> clipper: >> - improved Stroker to handle huge coordinates, up to 1E15 >> - improved PathClipFilter (filler) to handle huge coordinates, up to 1E15 >> >> >> This is the Marlin-renderer 0.9.4.3 release providing few bug / enhancement >> fixes in the MarlinRenderingEngine: >> - Update DPQS to latest OpenJDK 14 patch >> - Improve cubic curve offset computation >> >> >> The Marlin-renderer 0.9.4.2 release provides a single long-standing bug fix >> in the MarlinRenderingEngine: >> - JDK-8230728, https://bugs.openjdk.java.net/browse/JDK-8230728. >> >> >> Marlin-renderer 0.9.4.1 provides only a single bug fix in the path clipper, >> reported first against JavaFX 11: >> - JDK-8226789, https://bugs.openjdk.java.net/browse/JDK-8226789. >> >> >> This is the Marlin-renderer 0.9.4 release providing an updated Dual Pivot >> Quick Sort (19.05) as its internal sorter faster than the Marlin's optimized >> MergeSort (x-position + edge indices) for arrays larger than 256. >> >> Special Thanks to Vladimir Yaroslavskiy that provided me up-to-date DPQS >> 19.05 with many variants, improving almost-sorted datasets. We are >> collaborating to provide a complete Sort framework (15 algorithms, many >> various datasets, JMH benchmarks) publicly on github: >> see https://github.com/bourgesl/nearly-optimal-mergesort-code > > Laurent Bourgès has updated the pull request incrementally with one > additional commit since the last revision: > > added test for huge polygon coords Hi all, I'm the dpqs author and I worked with Laurent, so the proposed dpqs patch is our own IP that we agree to contribute under OCA to both openjdk & openjfx projects. - PR: https://git.openjdk.java.net/jfx/pull/674
Re: [jfx18] RFR: 8271085: TabPane: Redundant API docs
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote:
> This is a Javadoc cleanup and correction fix for the TabPane as described in
> the JBS.
>
> Changes done for all the Properties of the TabPane -
> - Moved the property description to be over the property field.
> - Removed the unnecessary docs on property setter/getter and Property method.
I looked at the first two properties, and they look fine. I'll do a detailed
review of the rest, but I wanted to point out one thing first. See below.
modules/javafx.controls/src/main/java/javafx/scene/control/TabPane.java line
188:
> 186: * the TabPane will immediately update the location of the tabs to
> reflect
> 187: * this.
> 188: * The default position for the tabs is {@code Side.Top}.
Ordinarily we would use a `@defaultValue` tag here. In this case, you are just
moving existing docs from one method to another, so it could be done in a
follow-up bug. Can you file a follow-up bug?
-
PR: https://git.openjdk.java.net/jfx/pull/728
Re: [jfx18] RFR: 8271085: TabPane: Redundant API docs
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in > the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. I'm reviewing this right now. - PR: https://git.openjdk.java.net/jfx/pull/728
Re: [jfx18] RFR: 8271085: TabPane: Redundant API docs
On Mon, 7 Feb 2022 10:53:00 GMT, Ajit Ghaisas wrote: > This is a Javadoc cleanup and correction fix for the TabPane as described in > the JBS. > > Changes done for all the Properties of the TabPane - > - Moved the property description to be over the property field. > - Removed the unnecessary docs on property setter/getter and Property method. Since we are in rampdown (RDP2) for JavaFX 18, I'd like @arapte to review this also. - PR: https://git.openjdk.java.net/jfx/pull/728
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2]
On Mon, 7 Feb 2022 10:24:01 GMT, Jose Pereda wrote: >> This PR adds a predicate to TableView and TreeTableView selection models >> order to remove rows from the selection only when there are no selected >> cells in that given row, when cell selection is enabled. >> >> Two tests have been added as well, that fail without this PR and pass with >> it. > > Jose Pereda has updated the pull request incrementally with one additional > commit since the last revision: > > Address feedback from reviewer getRow () returns an int. It is more efficient to process the primitive as it is. The code below will be less boxing. Because filter and distinct are processes for primitives It can be done at high speed. ``` java final List removed = c.getRemoved().stream() .mapToInt(TablePositionBase::getRow) .distinct() .filter(removeRowFilter) .boxed() .peek(sm.selectedIndices::clear) .collect(Collectors.toList()); final int addedSize = (int)c.getAddedSubList().stream() .mapToInt(TablePositionBase::getRow) .distinct() .boxed() .peek(sm.selectedIndices::set) .count(); - PR: https://git.openjdk.java.net/jfx/pull/709
Re: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6]
On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strauß wrote:
>> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype
>> specified for images encoded in data URIs. This should be improved as
>> follows:
>>
>> 1. If the specified image subtype is not supported, an exception will be
>> thrown.
>> 2. If the specified image subtype is supported, but the data contained in
>> the URI is of a different (but also supported) image format, the image will
>> be loaded and a warning will be logged. For example, if the MIME type is
>> "image/jpeg", but the image data is PNG, the following warning will be
>> generated:
>>
>>
>> Image format 'PNG' does not match MIME type 'image/jpeg' in URI
>> 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC'
>>
>>
>> Also, the javadoc of `javafx.scene.image.Image` incorrectly states:
>>
>> 94* If a URL uses the "data" scheme, the data must be base64-encoded
>> 95* and the MIME type must either be empty or a subtype of the
>> 96* {@code image} type.
>>
>> However, omitting the MIME type of a data URI is specified to imply
>> "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI`
>> class is implemented according to this specification, trying to load an
>> image without MIME type correctly fails with an `ImageStorageException`:
>> "Unexpected MIME type: text".
>>
>> The solution is to fix the documentation:
>>
>> 94* If a URL uses the "data" scheme, the data must be
>> base64-encoded
>> - 95* and the MIME type must either be empty or a subtype of the
>> - 96* {@code image} type.
>> + 95* and the MIME type must be a subtype of the {@code image} type.
>> + 96* The MIME type must match the image format of the data
>> contained in
>> + 97* the URL. In case of a mismatch between MIME type and image
>> format,
>> + 98* the image will be loaded if the image format can be determined
>> by
>> + 99* JavaFX, and a warning will be logged.
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Don't let EOFException bubble up
At least the following method do not need to remove the static modifier, but
they do. Is there any benefit?
``` java
public int getNumBands(ImageType type) {
-
PR: https://git.openjdk.java.net/jfx/pull/676
[jfx18] Integrated: 8279345: Realign class docs of LightBase and subclasses
On Sun, 16 Jan 2022 22:54:22 GMT, Nir Lisker wrote: > Now that the standard concrete light types were added, there is an > opportunity to rearrange and rewrite some of the class docs. Here is a > summary of the changes: > > * Moved the explanations of attenuation and direction up to `LightBase` since > different light types share characteristics. `LightBase` now contains a > summary of its subtypes and all the explanations of the > properties/characteristics of the lights divided into sections: Color, Scope, > Direction, Attenuation. > * Each light type links to the relevant section in `LightBase` when it > mentioned the properties it has. > * Added examples of real-world applications for each light type. > * Consolidated the writing style for all the subclasses. This pull request has now been integrated. Changeset: ed399825 Author:Nir Lisker URL: https://git.openjdk.java.net/jfx/commit/ed39982515e1f4399841ffd75849988ff651396d Stats: 152 lines in 5 files changed: 96 ins; 26 del; 30 mod 8279345: Realign class docs of LightBase and subclasses Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/717
Re: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5]
On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an >> opportunity to rearrange and rewrite some of the class docs. Here is a >> summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` >> since different light types share characteristics. `LightBase` now contains >> a summary of its subtypes and all the explanations of the >> properties/characteristics of the lights divided into sections: Color, >> Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it >> mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Changed description of ambient light Thanks for the reviews everyone! - PR: https://git.openjdk.java.net/jfx/pull/717
Re: JavaFX with Python/JS
Hi Thiago, Yes, that is possible, and I've done that years ago with some simple python code, that resulted in a array of numbers that can then be visualised with JavaFX. It is really cool indeed, but back then the Python support was limited (e.g. no numpy). As for huge marketing opportunity: the problem is most often that someone has to *do* the marketing. Which is typically harder/more expensive than doing the technical work. But from a pure technical point: it makes very much sense. - Johan On Mon, Feb 7, 2022 at 2:21 PM Thiago Milczarek Sayão < thiago.sa...@gmail.com> wrote: > Hi, > > Would it be possible to use JavaFx with python/graalvm ? > Maybe javascript? > > Gluon, > > Would that not be a huge marketing opportunity? Write apps in python/js ? > > Cheers. >
Re: [jfx18] RFR: 8279345: Realign class docs of LightBase and subclasses [v5]
On Fri, 4 Feb 2022 18:26:57 GMT, Nir Lisker wrote: >> Now that the standard concrete light types were added, there is an >> opportunity to rearrange and rewrite some of the class docs. Here is a >> summary of the changes: >> >> * Moved the explanations of attenuation and direction up to `LightBase` >> since different light types share characteristics. `LightBase` now contains >> a summary of its subtypes and all the explanations of the >> properties/characteristics of the lights divided into sections: Color, >> Scope, Direction, Attenuation. >> * Each light type links to the relevant section in `LightBase` when it >> mentioned the properties it has. >> * Added examples of real-world applications for each light type. >> * Consolidated the writing style for all the subclasses. > > Nir Lisker has updated the pull request incrementally with one additional > commit since the last revision: > > Changed description of ambient light Marked as reviewed by arapte (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/717
[jfx18] RFR: 8271085: TabPane: Redundant API docs
This is a Javadoc cleanup and correction fix for the TabPane as described in the JBS. Changes done for all the Properties of the TabPane - - Moved the property description to be over the property field. - Removed the unnecessary docs on property setter/getter and Property method. - Commit messages: - Fix Property javadocs Changes: https://git.openjdk.java.net/jfx/pull/728/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=728=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8271085 Stats: 122 lines in 1 file changed: 17 ins; 97 del; 8 mod Patch: https://git.openjdk.java.net/jfx/pull/728.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/728/head:pull/728 PR: https://git.openjdk.java.net/jfx/pull/728
Re: RFR: 8277572: ImageStorage should correctly handle MIME types for images encoded in data URIs [v6]
On Sat, 8 Jan 2022 17:30:55 GMT, Michael Strauß wrote:
>> `com.sun.javafx.iio.ImageStorage` currently ignores the MIME image subtype
>> specified for images encoded in data URIs. This should be improved as
>> follows:
>>
>> 1. If the specified image subtype is not supported, an exception will be
>> thrown.
>> 2. If the specified image subtype is supported, but the data contained in
>> the URI is of a different (but also supported) image format, the image will
>> be loaded and a warning will be logged. For example, if the MIME type is
>> "image/jpeg", but the image data is PNG, the following warning will be
>> generated:
>>
>>
>> Image format 'PNG' does not match MIME type 'image/jpeg' in URI
>> 'data:image/jpeg;base64,iVBORw0KGgoAAA...AAAElFTkSuQmCC'
>>
>>
>> Also, the javadoc of `javafx.scene.image.Image` incorrectly states:
>>
>> 94* If a URL uses the "data" scheme, the data must be base64-encoded
>> 95* and the MIME type must either be empty or a subtype of the
>> 96* {@code image} type.
>>
>> However, omitting the MIME type of a data URI is specified to imply
>> "text/plain" (RFC 2397, section 2). Since the `com.sun.javafx.util.DataURI`
>> class is implemented according to this specification, trying to load an
>> image without MIME type correctly fails with an `ImageStorageException`:
>> "Unexpected MIME type: text".
>>
>> The solution is to fix the documentation:
>>
>> 94* If a URL uses the "data" scheme, the data must be
>> base64-encoded
>> - 95* and the MIME type must either be empty or a subtype of the
>> - 96* {@code image} type.
>> + 95* and the MIME type must be a subtype of the {@code image} type.
>> + 96* The MIME type must match the image format of the data
>> contained in
>> + 97* the URL. In case of a mismatch between MIME type and image
>> format,
>> + 98* the image will be loaded if the image format can be determined
>> by
>> + 99* JavaFX, and a warning will be logged.
>
> Michael Strauß has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Don't let EOFException bubble up
Marked as reviewed by arapte (Reviewer).
-
PR: https://git.openjdk.java.net/jfx/pull/676
RFR: 8280841: Update SQLite to 3.37.2
Updated SQLite to 3.37.2 released on 2022-01-06 from the current version 3.32.3. Website : https://www.sqlite.org/index.html Source code can be found from https://www.sqlite.org/download.html at [sqlite-amalgamation-3370200.zip](https://www.sqlite.org/2022/sqlite-amalgamation-3370200.zip) Verified the updated version with unit tests and sanity testing. No issues are observed. - Commit messages: - Remove trailing whitespaces - Update SQLite to 3.37.2 Changes: https://git.openjdk.java.net/jfx/pull/727/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=727=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280841 Stats: 22876 lines in 4 files changed: 11629 ins; 3597 del; 7650 mod Patch: https://git.openjdk.java.net/jfx/pull/727.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/727/head:pull/727 PR: https://git.openjdk.java.net/jfx/pull/727
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2]
On Fri, 4 Feb 2022 17:33:18 GMT, Michael Strauß wrote: >> Jose Pereda has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Address feedback from reviewer > > modules/javafx.controls/src/main/java/javafx/scene/control/ControlUtils.java > line 172: > >> 170: .map(TablePositionBase::getRow) >> 171: .filter(removeRowFilter) >> 172: .distinct() > > Maybe `distinct` should be applied before `filter`. This can cut down the > number of times the predicate is invoked (which iterates over all selected > cells, so it may be a performance issue for large selections). Makes sense. Done - PR: https://git.openjdk.java.net/jfx/pull/709
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected [v2]
> This PR adds a predicate to TableView and TreeTableView selection models > order to remove rows from the selection only when there are no selected cells > in that given row, when cell selection is enabled. > > Two tests have been added as well, that fail without this PR and pass with it. Jose Pereda has updated the pull request incrementally with one additional commit since the last revision: Address feedback from reviewer - Changes: - all: https://git.openjdk.java.net/jfx/pull/709/files - new: https://git.openjdk.java.net/jfx/pull/709/files/34491051..fe943d4b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=709=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=709=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/709.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/709/head:pull/709 PR: https://git.openjdk.java.net/jfx/pull/709
Re: RFR: 8273336: Clicking a selected cell from a group of selected cells in a TableView clears the selected items list but remains selected
On Sat, 5 Feb 2022 05:08:54 GMT, yosbits wrote:
>> This PR adds a predicate to TableView and TreeTableView selection models
>> order to remove rows from the selection only when there are no selected
>> cells in that given row, when cell selection is enabled.
>>
>> Two tests have been added as well, that fail without this PR and pass with
>> it.
>
> Why not use IntPredicate?
>
> before
>
> ``` java
> public static void updateSelectedIndices(MultipleSelectionModelBase sm,
> ListChangeListener.Change> c,
> Predicate removeRowFilter) {
>
>
> after
>
> ``` java
> public static void updateSelectedIndices(MultipleSelectionModelBase
> sm,
> ListChangeListener.Change> c,
> IntPredicate removeRowFilter) {
>
>
> before
> ``` java
> .map(TablePositionBase::getRow)
>
>
> after
> ``` java
> .mapToInt(TablePositionBase::getRow)
@yososs Do you see any possible gain by using `IntPredicate` vs
`Predicate?
It changes the `Stream` to `IntStream`, and that needs an extra
`.boxed()` operation (or alternatively an extra operation to transform the int
array with `.collect(ArrayList::new, ArrayList::add, ArrayList::addAll)`).
So I'm wondering if this is worthy?
-
PR: https://git.openjdk.java.net/jfx/pull/709
Re: RFR: 8255940: localStorage is null after window.close() [v3]
On Sun, 6 Feb 2022 11:54:14 GMT, Jay Bhaskar wrote:
>> No, it's not OK for two reasons:
>>
>> 1. It prevents concurrent execution of tests from two different directories
>> 2. The Java temp directory might be something other than "/tmp" on some
>> systems.
>>
>> Best is to use a local subdir under the build directory.
>
> i am unable to find other test case which uses local sub-directory in the
> build dir so let me know i can use this
> String defaultBaseDir = System.getProperty("java.io.tmpdir");
> webEngine.setUserDataDirectory(new File(defaultBaseDir +
> "localstorage")
I have updated your suggestions and used local dir for setUserDataDirectory
-
PR: https://git.openjdk.java.net/jfx/pull/703
Re: RFR: 8255940: localStorage is null after window.close() [v3]
> Issue: The current implementation of DOMWindow ::localStorage(..) returns > null pointer in case of page is being closed. > Fix: It should not return nullptr , as per the [w3c web storage > spec](https://www.w3.org/TR/2016/REC-webstorage-20160419/) > "User agents should expire data from the local storage areas only for > security reasons or when requested to do so by the user. User agents should > always avoid deleting data while a script that could access that data is > running." Jay Bhaskar has updated the pull request incrementally with three additional commits since the last revision: - Change Dir Path and use local Dir and set data before clearing localstorage test - Merge branch 'PRLocalstorage' of https://github.com/jaybhaskar/jfx into PRLocalstorage - Merge branch 'master' into PRLocalstorage - Changes: - all: https://git.openjdk.java.net/jfx/pull/703/files - new: https://git.openjdk.java.net/jfx/pull/703/files/73299577..a8647839 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=703=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=703=01-02 Stats: 78 lines in 3 files changed: 68 ins; 1 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/703.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/703/head:pull/703 PR: https://git.openjdk.java.net/jfx/pull/703
