Re: JavaFX 17 Maven Artifacts

2021-09-10 Thread Scott Palmer
I still think having .jmod files available from an artifact repository would be 
helpful.  I’ve deployed them from the SDK to my local Artifactory repo for my 
own builds.  Using Gradle I create a JRE with jlink if needed for running 
debug/tests during development, or I use an OpenJDK distribution that has 
bundled in JavaFX (like those available from Azul or BellSoft). The primary 
downside of using the .jmod files is that they can’t be used at runtimes o you 
need to build a JRE, but that is the recommended practice now for distributing 
applications anyway.  I use jpackage for distribution so I'm bundling a JRE 
with the JavaFX modules.

Using .jar files for libraries that contain native code is messy IMO.  JMOD 
files are supposed to solve that - they should be the preferred way to include 
JavaFX in a build, but installing the JavaFX SDK is a pain when we use 
dependency management for everything else.

Scott

> On Sep 10, 2021, at 9:10 AM, Abhinay Agarwal  wrote:
> 
> JavaFX 17 Maven artifacts currently fail to compile modular JavaFX 
> application. The non-modular application still works.
> 
> To explain what's going on, let have a look at JavaFX and its Maven 
> distribution since version 11:
> 
> 1. JavaFX is distributed in non-platform (empty) and platform specific 
> artifacts
> 2. These artifacts along with the javafx plugins have helped developers to 
> use JavaFX in platform agnostic way
> 3. Platform jars have the `module-info.java` file, whereas, 
> `Automatic-Module-Name` was present in the empty jar's MANIFEST.MF.
> 4. However, using `maven-jlink-plugin` with a JavaFX application fails since 
> Automatic modules are not supported in JLink [1]
> 5. After a brief discussion, it was decided to remove the Automatic Module 
> Name from non-platform jars [2]
> 
> The EA releases were working perfectly after the change was made. However, 
> with recent JavaFX 17, modular applications are failing to compile with Maven.
> 
> The reason behind this lies in the `plexus-java` library used by 
> `maven-compiler-plugin`:
> 
> 1. `plexus-java` doesn't allow duplicate entries with same module-name on 
> module-path
> 2. For 17, `plexus-java` resolves both empty and platform jar to have the 
> same module-name
> 3. However, with `-ea+xx`, `plexus-java` resolves the module name for empty 
> jar as null and we never discovered the bug until 17 was released
> 
> 17
> ---
> /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17.jar
> org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@c1c939a0
> Module Name: javafx.controls
> /home/.m2/repository/org/openjfx/javafx-controls/17/javafx-controls-17-linux.jar
> org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@31c3da0e
> Module Name: javafx.controls
> 
> 17-ea+18
> 
> /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18.jar
> Module Name: null
> /home/.m2/repository/org/openjfx/javafx-controls/17-ea+18/javafx-controls-17-ea+18-linux.jar
> org.codehaus.plexus.languages.java.jpms.JavaModuleDescriptor@c896ba80
> Module Name: javafx.controls
> 
> X
> 
> This whole experience has made us realised we need to rethink how we package 
> JavaFX Maven artifacts.
> We are still discussing about the approach and naming, but we are throwing it 
> out in the open to gather feedback:
> 
> 1. Instead of 1 module per component, we will have 2 modules (javafx.base.api 
> and javafx.base.platform)
> 2. The `javafx.base.api`, unlike empty jar, will contain all generic Java code
> 3. The `javafx.base.platform` will contain platform-specific native + Java 
> code
> 4. Current application declare their module-descriptor as:
> 
> ```
> module app {
>requires javafx.base;
> }
> ```
> 
> 5. In future this may be changed depending on how we end up wiring these 
> modules together:
> 
> ```
> module app {
>requires javafx.base [.api or .platform];
> }
> ```
> 
> 
> [1] https://www.mail-archive.com/dev@maven.apache.org/msg123978.html
> [2] https://bugs.openjdk.java.net/browse/JDK-8264998



Re: RFR: 8270107: Open source FXMediaPlayer test app

2021-08-29 Thread Scott Palmer
On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev  
wrote:

> - Added FXMediaPlayer test application.
>  - This app uses all media APIs and very handy in verifying media builds 
> during development.
>  - It can be compiled and run by running "ant" and "ant run" in 
> tests/manual/media/FXMediaPlayer.

> On Aug 28, 2021, at 11:51 AM, Kevin Rushforth ***@***.***> wrote:
> 
> 
> I agree with getting it in now (after testing) and then improving it after it 
> is in the repo.
> 
> Btw, the nbproject/ files were derived from those in the apps/toys/ 
> directory, for example, apps/toys/Hello/nbproject/ 
> ,
>  and similarly are used to build using ant. So they aren't really IDE files 
> any longer, even though that's where they originated back in the FX 2 time 
> frame.
> 
> A good cleanup effort would be to rewrite them to remove the NetBeans project 
> structure, but that would be a larger effort than just this one manual test 
> program.
> 


Would be nice to have part of the cleanup convert projects to Gradle to be 
consistent with the rest of the project.

Scott

-

PR: https://git.openjdk.java.net/jfx/pull/613


Re: Enhancements for JavaFX 18

2021-08-04 Thread Scott Palmer
+1 to that. 

I would also like to see some progress with system tray support and microphone 
& webcam access. 

Scott

> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg  
> wrote:
> 
> 
> my suggestion would be the longstanding commit-edit-on-focus-lost - solved by 
> an enhancement to the editing api on virtualized controls
> 
> -- Jeanette
> 
> Zitat von Kevin Rushforth :
> 
>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
>> enhancement requests for JavaFX 18. It's the summer, so there may be delays 
>> as some people are out at various times (including me), but I would like to 
>> get some of the outstanding enhancement requests moving over the next few 
>> weeks.
>> 
>> Specifically, I'd like to see the following proceed:
>> 
>> * Transparent backgrounds in WebView
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>> PR: https://github.com/openjdk/jfx/pull/563
>> 
>> * Add DirectionalLight
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>> PR: https://github.com/openjdk/jfx/pull/548
>> 
>> * CSS pseudoclasses :focus-visible and :focus-within
>> https://bugs.openjdk.java.net/browse/JDK-8268225
>> PR: https://github.com/openjdk/jfx/pull/475
>> 
>> * Improve property system to facilitate correct usage (minus the binary 
>> incompatible API change)
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>> 
>> And maybe the following:
>> 
>> * Add CSS themes as a first-class concept (need a consensus on how to 
>> proceed)
>> 
>> * Undecorated interactive stage style (still in early discussion, but the 
>> concept looks interesting and useful)
>> 
>> There are probably others I'm forgetting.
>> 
>> Each of the above should be discussed in their own thread on openjfx-dev 
>> rather than a reply to this thread.
>> 
>> -- Kevin
> 
> 
> 


Re: RFR: 8223717: javafx printing: Support Specifying Print to File in the API [v3]

2021-06-24 Thread Scott Palmer
On Thu, 24 Jun 2021 22:25:53 GMT, Kevin Rushforth  wrote:

>> Phil Race has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   8223717: javafx printing: Support Specifying Print to File in the API
>
> modules/javafx.graphics/src/main/java/javafx/print/JobSettings.java line 474:
> 
>> 472:  * encoded name of a filesystem file, to which the platform printer
>> 473:  * driver should spool the rendered print data.
>> 474:  * 
> 
> Can you add a sentence indicating that the URL needs to be a `file:` URL? And 
> indicate what happens if it isn't (I presume it is ignored)?

As a potential user of this API I have to ask, why would this be a URL instead 
of a File or Path ?  Particularly if only "file:" URLs will be valid.  I can't 
think of a scenario where it won't always be an extra inconvenience to convert 
the path I have to a URL.

-

PR: https://git.openjdk.java.net/jfx/pull/543


Re: [External] : Re: Convenience factories for Border and Background

2021-06-08 Thread Scott Palmer
+1 for having a variant that takes a width. Colour, width, and radius are the 
main parameters I need, so a variant that takes all three would help:

 Border.stroke(Paint p, double width, double radii) 

(Though to be honest for my larger projects most of the time this stuff is set 
in a style sheet.  It’s smaller tools and utilities that I find this 
particularly tedious as the verbosity of the code becomes annoying.)

Scott

> On Jun 8, 2021, at 9:59 AM, Kevin Rushforth  
> wrote:
> 
> I think that the convenience methods should just cover the most common cases, 
> so I'd rather skip the dotted and dashed variants. It is a good question as 
> to whether there ought to be a variant that takes width. I wouldn't do that 
> as the only method, though. I'd lean towards not taking the width. Once you 
> start getting into more parameters you can just use the constructors without 
> much more trouble.
> 
> As for the names, I have a slight preference for Border.stroke and 
> Background.fill.
> 
> -- Kevin
> 
> 
> On 6/8/2021 4:25 AM, Nir Lisker wrote:
>> Are dashed and dotted used frequently? I find that I only use solid unless 
>> I'm doing something fancy.
>> 
>> On Tue, Jun 8, 2021 at 5:21 AM Michael Strauß > > wrote:
>> 
>>What do you think about this variation?
>> 
>>Border.solid(Paint color, double width) ->
>>new Border(new BorderStroke(color, BorderStrokeStyle.SOLID,
>>null, new BorderWidths(width)))
>> 
>>Border.dashed(Paint color, double width)  ->
>>new Border(new BorderStroke(color, BorderStrokeStyle.DASHED,
>>null, new BorderWidths(width)))
>> 
>>Border.dotted(Paint color, double width) ->
>>new Border(new BorderStroke(color, BorderStrokeStyle.DOTTED,
>>null, new BorderWidths(width)))
>> 
>>Background.fill(Paint color) ->
>>new BackgroundFill(color, null, null)
>> 
>>This gives developers a good deal of customizability before needing to
>>fall back to using constructors.
>> 
>> 
>>Am Di., 8. Juni 2021 um 03:21 Uhr schrieb Nir Lisker
>>mailto:nlis...@gmail.com>>:
>>>
>>> The new API:
>>>
>>> 1. `Border.of(Paint stroke)` or `Border.stroke(Paint stroke)`
>>that does
>>> `new Border(new BorderStroke(Paint stroke ,
>>BorderStrokeStyle.SOLID, null,
>>> null));`
>>> 2. `Background.of((Paint fill)` or `Background.fill(Paint fill)`
>>that does
>>> `new Background(new BackgroundFill(Paint fill, null, null));`
>>>
>>> I don't mind either name choice.
>>>
>> 
> 



Re: RFR: 8263760: Update gradle to version 7.0.1 [v2]

2021-05-14 Thread Scott Palmer
On Thu, 13 May 2021 21:55:59 GMT, Kevin Rushforth  wrote:

>> This PR fixes the gradle deprecation warnings described in 
>> [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) and updates 
>> the JavaFX build to use gradle 7.0.1 as described in 
>> [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760). The minimum 
>> version of gradle is set to 6.3.
>> 
>> In addition to keeping gradle up to date, updating to gradle 7 will allow 
>> building and testing JavaFX with JDK 16.
>> 
>> I have done a full build and test on all three platforms, comparing the 
>> artifacts produced before and after this change.
>> 
>> ### Notes to Reviewers:
>> 
>> The PR branch has two separate commits, one for each fix, in case reviewers 
>> want to look at them separately. As always, they will be squashed into a 
>> single commit when integrated. Both bug IDs will be listed in the commit.
>> 
>> The following changes were done for 
>> [JDK-8240336](https://bugs.openjdk.java.net/browse/JDK-8240336) to eliminate 
>> the use of deprecated features removed in gradle 7:
>> 
>> 1. Replaced `compile` with either `implementation` or `compileClasspath` as 
>> needed
>> 2. Replaced obsolete `archiveName` and `destinationDir` properties in 
>> archive tasks with `archiveFileName` and `destinationDirectory`
>> 3. Added missing `@Input` annotation to custom Groovy task properties
>> 4. Bumped the minimum version of gradle to 6.3 (which we have been using for 
>> more than 1 year)
>> 
>> 
>> The following changes were done for 
>> [JDK-8263760](https://bugs.openjdk.java.net/browse/JDK-8263760) to update to 
>> gradle 7.0.1:
>> 
>> 1. Ran `bash ./gradlew wrapper --gradle-version=7.0.1`
>> 2. Updated the gradle version in `build.properties` to `7.0.1`
>> 3. Updated the SHA-256 checksum in `gradle/wrapper/gradle-wrapper.properties`
>
> Kevin Rushforth has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   Revert "Revert auto-generated change to DEFAULT_JVM_OPTS in gradlew scripts"
>   
>   This reverts commit 0b70d096055f5b5c892f052d5eee54da357eab63.

Isn't that just the settings for running the gradle wrapper - i.e.  it is not 
setting the heap used by the gradle daemon process that will actually run the 
build script?
I only see it used one spot in the script to run the gradle-wrapper.jar, in 
which case it makes sense that it is intentionally set low as the wrapper 
itself isn't doing much other than ensuring the correct version of Gradle is 
used.

-

PR: https://git.openjdk.java.net/jfx/pull/498


Re: Add method to save a JavaFX image to file without the use of SwingFXUtils?

2021-05-04 Thread Scott Palmer
An overhaul to ImageIO that isn’t dependent on any UI framework, but rather 
accesses raw image data via arrays or ByteBuffer (or even the new foreign 
MemoryAccess stuff?) would help. 
For specific UI framework types, BufferedImage and JavaFX Image, they just need 
the plumbing to get the raw data accessible to ImageIO v2.   That way we don’t 
need to mix different UI modules to read and write images.  There are already 
too many ways to read images in the JDK, it would help if they could all 
delegate to a single body of code.

It also might help with some cases of server-side image generation, where a 
full UI toolkit isn’t needed... e.g. only the JavaFX graphics module (and base) 
is enough to generate images.

Is anything like that every likely to happen?

Scott

> 
> On May 4, 2021, at 8:21 AM, Kevin Rushforth  
> wrote:
> 
> Hi,
> 
> We've discussed adding image reading and writing functionality in the past. 
> Something on the order of Java2D's Image I/O. Doing it right would be a large 
> project, and would be more than just adding a couple methods to JavaFX Image. 
> Unless and until we do that, using the SwingFXUtils to produce a 
> BufferedImage from a JavaFX Image is the recommended approach.
> 
> -- Kevin
> 
> 
>> On 5/4/2021 5:08 AM, Frank Delporte wrote:
>> Hello
>> 
>> My first contribution to this mailing list... ;-)
>> 
>> During an experiment with FXGL on the Raspberry Pi + Gluon JavaFX 17-ea, it 
>> turned out there was a missing dependency to javafx.swing.
>> (also mentioned here 
>> )
>> 
>> Turns out SwingFXUtils was used in the FXGL library only to be able to save 
>> a screenshot of the application to a file and we were able to rework it as 
>> you can see here: 
>> 
>> 
>> I researched this topic for a few hours, but didn't manage to find a good 
>> approach to save a JavaFX Image. Maybe I missed something? Or wouldn't it be 
>> a good idea to extend the JavaFX Image or BufferedImage with e.g. 
>> writeToFile(ImageFormat.PNG), writeToFile(ImageFormat.JPG)?
>> 
>> Best regards
>> Frank Delporte
>> 
>> Want to have coding-fun?
>> Check my blogand book "Getting started with Java on 
>> Raspberry Pi" on
>> 
>> 
> 


Re: [External] : Re: Consistent baseline layout algorithm

2021-04-16 Thread Scott Palmer
“ I've changed the default alignment for
Label to TOP_LEFT (the default alignment of the base class Labeled is
CENTER_LEFT).”

How can you do that without breaking things?  Even though it may be uncommon to 
set minHeight or prefHeight, that isn’t the point.  It still breaks existing 
code.

Scott

> On Apr 16, 2021, at 12:48 AM, Michael Strauß  wrote:
> 
> I've learned a few new things while working on the proposed new layout
> algorithm, and added a few new APIs:
> 
> 
> 1. A central concept of the new algorithm was the notion of a
> text-baseline node, indicated by Node::isTextBaseline(). I've come to
> realize that this property should percolate upwards in the scene
> graph: if a node has a text-baseline, the node's parent should also be
> considered to have a text-baseline. Adding this new behavior works
> surprisingly well and produces very intuitive layout results.
> 
> 
> 2. The default behavior of all layout containers is to pick the first
> text-baseline child to derive their own baseline offset. I've added
> Node::prefBaselineProperty(), which makes it possible to override this
> default selection: layout containers now pick the first child that
> reports Node::isPrefBaseline(), and only if there is no such child,
> they fall back to Node::isTextBaseline(). Developers can use this
> property to fine-tune their baseline layouts.
> 
> 
> 3. Optimization: Controls that contain text will often consist of a
> container of some sort and a javafx.scene.text.Text node within it.
> Computing the baseline offset of such a control is very easy with the
> new layout algorithm:
> 
> public double getBaselineOffset() {
>return text.getLayoutBounds().getMinY() + text.getLayoutY() +
> text.getBaselineOffset();
> }
> 
> This works because changing text.layoutY will automatically schedule
> another layout pass for all of its parents. Re-layouting all parents
> is necessary because changing layoutY can change the effective
> baseline offset, and changing the baseline offset of any node can have
> layout implications on any of its parents.
> 
> However, when we consider the Label control (which is probably among
> the most commonly used controls), this can be a bit excessive. Label
> controls are often used to display pure text, and as such, we can
> often "know" the baseline offset without actually needing to schedule
> a second layout pass. This assumption is only correct if the text
> within the Label is top-aligned (because if it isn't, the Label
> baseline offset can not be known in advance of an actual layout pass).
> 
> To leverage this assumption, I've changed the default alignment for
> Label to TOP_LEFT (the default alignment of the base class Labeled is
> CENTER_LEFT). In most cases, there will be no visual difference
> anyway, because I imagine Label controls will seldomly be set to a
> minHeight or prefHeight.
> 
> This specific scenario will enable an optimization where the first
> layout pass of Label will not schedule a second layout pass. It might
> be possible to find more such scenarios that can benefit from
> fast-path optimizations.
> 
> 
> 4. In order to get a better understanding of the layout process, I
> added additional logging to track layout passes. Then I compared the
> current algorithm with the new algorithm by tracking the initial
> layout after starting a sample program (i.e. all layout activity until
> the first frame is rendered). In the following log, "cumulative layout
> passes" means how often layoutChildren() has been invoked on any of
> the scene graph nodes. The actual log output includes a tree
> visualization of the entire scene graph that is being layouted, which
> I've removed for the sake or brevity.
> 
> Current algorithm log output:
> INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative
> layout passes: 49
> INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 43
> INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 0
> 
> New algorithm log output:
> INFO: Layouting VBox (triggered by scene out-of-pulse), cumulative
> layout passes: 86
> INFO: Layouting VBox (triggered by scene pulse), cumulative layout passes: 19
> 
> A major difference is that the current algorithm will often leave the
> scene graph in a 'dirty' layout state after running a complete layout
> cycle, which necessitates another layout cycle as part of the next
> pulse. The new algorithm, however, leaves the scene graph in a clean
> layout state after a complete cycle, which takes more work at first,
> but saves work that would otherwise be done in the next pulse.
> 
> 
> 5. Since the new layout algorithm will leave the scene graph in a
> clean state, it is not necessary to repeatedly layout the same thing
> (like in Node::doLayoutPass()). Cases like these should be identified
> and may be changed to single layout invocations.
> 
> 
> Overall, I think there's good reason to assume that the proposed
> algorithm works and that it produces 

Re: [External] : Re: Consistent baseline layout algorithm

2021-04-02 Thread Scott Palmer
I haven’t done much in terms of custom controls, but I do see this issue a lot 
in my primary application.  It would be nice to have it fixed as the layout 
looks rather sloppy without it.  Any time I see the layout “correct” itself 
when I interact with a control or tweak the size of a window it is also 
distracting.
When I saw this fix proposed here my first thought was, “finally!”  So I for 
one am looking forward to this.  It seems that the number of iterations will be 
very low for most cases, so I’m not terribly concerned about any sort of 
performance impact.  But that is my only worry, as I have had issues with 
layout/CSS taking a lot of time in the past, so in some cases even a single 
extra iteration may lead to a perceptible delay.  (I was mostly working with FX 
8 when I had those issues, so hopefully things are better in recent versions, I 
haven’t measured.)
I agree that the default limit could probably be reduced, 10 iterations would 
likely be plenty more than needed.  As you say, something is probably wrong 
with your control if it goes that far.

Regards,

Scott


> On Apr 2, 2021, at 10:51 AM, Kevin Rushforth  
> wrote:
> 
> Circling back to this: Do any JavaFX application developers on this list 
> have any thoughts? I think this is a good idea, and it seems worth moving 
> this forward, but it will require a fair bit of effort. I'd like to hear 
> buy-in from other developers -- particularly those who develop or use custom 
> controls.
> 
> A few additional comments:
> 
> * Regarding the threshold, I like the idea of logging at a fine (or finer) 
> level if it goes beyond a smaller number, say 3 or 4, passes, but continuing 
> further to iterate. I wonder if 100 might be too large for the default limit, 
> though. It seems likely that the control is unstable and will never converge 
> if it gets to that many layout passes. If there were a way to analyze what a 
> reasonable limit is that would be better (if not, we can probably live with a 
> fairly high value, if it really is an unlikely pathological case). Assuming a 
> reasonably high threshold, logging at a warning level would be good if it 
> doesn't converge.
> 
> * Documentation: I do think we will want to document the overall concept of 
> layout needing multiple passes to converge in some cases, along with 
> documenting the threshold. I also think that Node::getBaselineOffset should 
> mention the preference of text nodes. The concept of "text" nodes needs to be 
> on Node, if for no other reason than that Text doesn't inherit from Parent.
> 
> * This will need to be very well tested, both to ensure no regressions in 
> behavior, and with many new tests added to validate the new functionality, 
> including testing the threshold logic.
> 
> -- Kevin
> 
> 
>> On 3/20/2021 6:42 AM, Michael Strauß wrote:
>> 1) Pathological cases: So far, I haven't been able to produce
>> pathological cases that exceed 3 layout passes by using standard
>> layout containers and controls. If we need to have a threshold
>> substantially higher than that depends on whether or not there are
>> indeed legitimate cases where some kind of layout requires more passes
>> to converge. Maybe we could log at a very fine level when a control
>> takes more than 3 passes to converge, but still continue processing up
>> to a substantially higher number of passes. This would allow
>> developers to debug and optimize their custom controls, but still
>> produce a valid solution if a particular control is generally stable,
>> but just very poorly optimized.
>> 
>> 2) I believe that the multi-pass layout algorithm shouldn't need
>> additional documentation since it could be considered an
>> implementation detail. There is no 1:1 correspondence between pulses
>> and layout passes currently, and there won't be with the new
>> algorithm. Also, any layout pass with the current algorithm can
>> potentially trigger another layout pass, so that's not fundamentally
>> different either. For control authors, we might need to document that
>> it is generally okay to rely on circular dependencies between size
>> hints, baseline offset and child nodes, as long as those dependencies
>> allow the layout to settle. The fact that text nodes are preferred
>> with respect to baseline computation is documented in
>> Parent.getBaselineOffset(), maybe Node.getBaselineOffset() should also
>> mention this. We might also add a section on baseline computation to
>> the javafx.scene.layout package documentation, where I think it is
>> most relevant (and currently entirely undocumented).
>> 
>> 3) New API on Node: in order for this idea to work, there needs to be
>> an abstract concept of "text node". Since the "baseline" concept is
>> introduced on Node, I thought this would also be the appropriate place
>> to introduce the "text node" concept; however, it could also be
>> introduced on Parent instead. Note that the "text node" concept is
>> introduced at a lower level than actual text 

Re: list digest

2020-12-22 Thread Scott Palmer
You might consider supplying your own sortPolicy (see sortPolicyProperty
).
It could remove your "total" object, call the DEFAULT_SORT_POLICY

and
then add your total object back.

Scott

On Sun, Dec 20, 2020 at 4:50 PM Chuck Davis  wrote:

> Thanks guys for the link to the digest.
>
> I've looked through a couple of years and find nothing that addresses my
> interest.  As background, I write financial applications and usually when a
> user selects something to display in a table it's because they're
> interested in the total amount.  And it is easy to provide that information
> to them on the initial display.
>
> The rub comes when they select a column header or otherwise sort the
> table.  I need, first of all, to eliminate the total object from the model
> (this is done easily by listening to the onSort property).  Then, after the
> sort is complete I need to add the total object back to the model.  If I
> don't eliminate the total object from the model the sort puts it in very
> strange places.  What I need to know is when the sort is complete so
> that I can add the total object back into the model and get it displayed.
>
> I've been looking at the TableView source and find the following code near
> the start of the sort() method:
> SortEvent> sortEvent = new SortEvent<>(TableView.this,
> TableView.this);
> fireEvent(sortEvent);
>
> It seems to me it would be trivial to invent another event type
> SORT_COMPLETE and emit it at the end of the sort() method to notify the
> program that the sort has been completed.  And that would certainly solve a
> major headache with showing a total amount for financial tables.  What I
> don't know is whether the sort is done on another thread in which case a
> Future would probably be required to detect the sort completion.
>
> If this were implemented we programmers would be able to detect both the
> start and completion of a sort of the table and proceed accordingly.  It
> would be VERY helpful.
>
> Thanks for reading.
>


Re: Taskbar API from JavaFX Window?

2020-11-02 Thread Scott Palmer
For that API, you might consider using an AWT root Window with a JFXPanel
rather than a JavaFX Window to hold your JavaFX UI.  But discussion of how
to code the application side is not relevant for this list.

For the record here are the relevant JavaFX issues:
https://bugs.openjdk.java.net/browse/JDK-8091107
https://bugs.openjdk.java.net/browse/JDK-8091517

If you want to discuss those further, this list might be the right place.
Currently JavaFX modules require the java.desktop module, so it doesn't
hurt your JRE footprint to use the Swing integration.  Hopefully
that dependency won't last long though (see
https://bugs.openjdk.java.net/browse/JDK-8240844), and perhaps at the point
the desktop module dependency is removed, the motivation to implement the
above issues will be higher.

Cheers,

Scott


On Mon, Nov 2, 2020 at 11:46 AM Will Iverson  wrote:

> What Window should I pass in for the setWindowProgressState window
> argument?  It requires a java.awt.Window?
>
> On Sun, Nov 1, 2020 at 5:48 PM Scott Palmer  wrote:
>
>> They work fine. Just remember to use the Swing/AWT event thread to call
>> them.
>>
>> Scott
>>
>> > On Nov 1, 2020, at 8:39 PM, Will Iverson  wrote:
>> >
>> > Looking at native desktop integration with JavaFX.  As I was
>> exploring, I
>> > noticed that the java.awt.Taskbar API does not appear to be available
>> for
>> > JavaFX Windows.
>> >
>> >
>> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State)
>> >
>> > Many of the other methods on this class (e.g. setting progress, custom
>> > icons) work fine on macOS from my testing so far.
>> >
>> > Is there any way to use the AWT methods from a JavaFX app?
>> >
>> > Cheers,
>> > -Will
>>
>


Re: Taskbar API from JavaFX Window?

2020-11-01 Thread Scott Palmer
They work fine. Just remember to use the Swing/AWT event thread to call them. 

Scott

> On Nov 1, 2020, at 8:39 PM, Will Iverson  wrote:
> 
> Looking at native desktop integration with JavaFX.  As I was exploring, I
> noticed that the java.awt.Taskbar API does not appear to be available for
> JavaFX Windows.
> 
> https://docs.oracle.com/javase/10/docs/api/java/awt/Taskbar.html#setWindowProgressState(java.awt.Window,java.awt.Taskbar.State)
> 
> Many of the other methods on this class (e.g. setting progress, custom
> icons) work fine on macOS from my testing so far.
> 
> Is there any way to use the AWT methods from a JavaFX app?
> 
> Cheers,
> -Will


Re: Tray Icon?

2020-07-31 Thread Scott Palmer
I should also point out that this shortcoming was identified nearly 9 years 
ago. 

https://bugs.openjdk.java.net/browse/JDK-8092115

I would love to make some progress on this, but I think doing it right is a 
bigger job than “outsiders” can tackle. Ideally most of the desktop APIs should 
be supported by JavaFX without AWT/Swing. I think that requires some careful 
thought. Some of the code should be independent of the UI toolkit and it could 
be shared between the AWT and JavaFX implementations. In a modular JRE we 
shouldn’t need the Swing modules to have a system tray icon in a JavaFX app.

Scott

> On Jul 31, 2020, at 7:34 PM, Scott Palmer  wrote:
> 
>  No you can’t. System tray support is something else, not an application 
> icon in the start bar or doc. 
> 
> Scott
> 
>> On Jul 31, 2020, at 6:02 PM, Michael Paus  wrote:
>> 
>> You can add such an icon to your JavaFX app if you bundle it with the 
>> jpackage tool distributed with JDK 14+
>> 
>>>> Am 31.07.20 um 23:07 schrieb Davide Perini:
>>> Hi all guys,
>>> love JavaFX, it's so productive, so easy to use, can't understand why the 
>>> world don't use it "for some tasks".
>>> 
>>> I know that tray icon can be easily done with AWT but is there something 
>>> for JavaFX?
>>> Is it possible to create a tray icon with JavaFX?
>>> 
>>> Thanks
>>> Davide
>> 
>> 
>> 


Re: Tray Icon?

2020-07-31 Thread Scott Palmer
 No you can’t. System tray support is something else, not an application icon 
in the start bar or doc. 

Scott

> On Jul 31, 2020, at 6:02 PM, Michael Paus  wrote:
> 
> You can add such an icon to your JavaFX app if you bundle it with the 
> jpackage tool distributed with JDK 14+
> 
>> Am 31.07.20 um 23:07 schrieb Davide Perini:
>> Hi all guys,
>> love JavaFX, it's so productive, so easy to use, can't understand why the 
>> world don't use it "for some tasks".
>> 
>> I know that tray icon can be easily done with AWT but is there something for 
>> JavaFX?
>> Is it possible to create a tray icon with JavaFX?
>> 
>> Thanks
>> Davide
> 
> 
> 


Re: How to create a fat jar for my JavaFX program?

2020-07-20 Thread Scott Palmer
jlink and jdeps are module-based, so you do have to be careful.  Neither will 
work properly when you try to run it against a non-modular project (found that 
out the hard way when Java 11 broke the world by removing the EE modules from 
Java SE and no modules were available to replace them), but you can use them to 
make a JRE image from a set of modules, such as those supplied by OpenJFX.

I still think the .jmod files should be hosted by artifact repositories to make 
this work smoothly.  Downloading an SDK, seems so old-school when we have good 
dependency-management tools.

Once you have a JRE image that includes JavaFX, then your application Jar files 
(all of them, no need to make anything 'fat') can easily be bundled with that 
JRE using jpackage.

I have done Gradle scripts to do all that and it wasn’t difficult.

Scott

> On Jul 20, 2020, at 1:39 PM, Michael Paus  wrote:
> 
> In order to create a real platform installer with jpackage and jlink/jdeps 
> you don't have to use the java
> module system at all. Have a look at this tutorial which I co-autored 
> together with Dirk Lemmermann:
> <https://github.com/dlemmermann/JPackageScriptFX>
> Michael
> 
> Am 20.07.20 um 19:25 schrieb Davide Perini:
>> Unfortunantly so few dependencies supports Java Modules this day, so fat JAR 
>> is the only way I can do it.
>> 
>> Thanks
>> 
>> Il 20/07/2020 02.50, Scott Palmer ha scritto:
>>> The JavaFX classes are there, but what about the native libraries?
>>> 
>>> A fat jar isn’t a good way to distribute a Java application these days. Now 
>>> you should probably be using jpackage and/or jlink to bundle your 
>>> application classes with a runtime suitable for running the application.
>>> 
>>> Scott
>>> 
>>>> On Jul 19, 2020, at 5:32 PM, Davide Perini  
>>>> wrote:
>>>> 
>>>> Hi all,
>>>> thanks for the great project, I love JavaFX.
>>>> 
>>>> I always used the maven plugin to crete fat jars with all my deps. The 
>>>> resulting jar is an executable one and ready to use.
>>>> 
>>>> This is my pom that create the fat jar.
>>>> 
>>>> but when I try to exceute the jar I get this error:
>>>> 
>>>> Error: JavaFX runtime components are missing, and are required to run this 
>>>> appli
>>>> cation
>>>> 
>>>> 
>>>> if I explode the fat jar I can see that there are the javafx class in it. 
>>>> what am I doing wrong?
>>>> 
>>>> Thanks
>>>> Davide
>>>> 
>>>>  org.openjfx 
>>>> javafx-maven-plugin 
>>>> ${javafx.maven.plugin.version}  
>>>> org.dpsoftware.FastScreenCapture  
>>>>   org.apache.maven.plugins 
>>>> maven-assembly-plugin  
>>>> ${project.build.directory}/ 
>>>> JavaFastScreenCapture   
>>>>  make-executable-jar-with-dependencies 
>>>> package  single  
>>>>true 
>>>> org.dpsoftware.FastScreenCapture  
>>>>   
>>>> jar-with-dependencies  
>>>>
>>>> 



Re: How to create a fat jar for my JavaFX program?

2020-07-19 Thread Scott Palmer
The JavaFX classes are there, but what about the native libraries?

A fat jar isn’t a good way to distribute a Java application these days. Now you 
should probably be using jpackage and/or jlink to bundle your application 
classes with a runtime suitable for running the application. 

Scott

> On Jul 19, 2020, at 5:32 PM, Davide Perini  
> wrote:
> 
> Hi all,
> thanks for the great project, I love JavaFX.
> 
> I always used the maven plugin to crete fat jars with all my deps. The 
> resulting jar is an executable one and ready to use.
> 
> This is my pom that create the fat jar.
> 
> but when I try to exceute the jar I get this error:
> 
> Error: JavaFX runtime components are missing, and are required to run this 
> appli
> cation
> 
> 
> if I explode the fat jar I can see that there are the javafx class in it. 
> what am I doing wrong?
> 
> Thanks
> Davide
> 
>  org.openjfx 
> javafx-maven-plugin 
> ${javafx.maven.plugin.version}  
> org.dpsoftware.FastScreenCapture  
>   org.apache.maven.plugins 
> maven-assembly-plugin  
> ${project.build.directory}/ 
> JavaFastScreenCapture   
>  make-executable-jar-with-dependencies 
> package  single   
>   true 
> org.dpsoftware.FastScreenCapture  
>   
> jar-with-dependencies  
>
> 


Re: MacOS Big Sur and OpenJFX on Arm Macs

2020-07-01 Thread Scott Palmer
JavaFX already runs on some Arm-based devices like the Raspberry Pi, so I 
expect an Arm-based port for new Macs won’t be that big of a job (relatively 
speaking)

Hopefully by that time there will be a Metal-base rendering pipeline as well. 
The Metal-based pipeline for Swing seems to be coming along nicely.

I don’t know if Oracle has access to one of the early developer boxes that runs 
macOS on arm or not. If they don’t, then a Java/Java FX port may not be 
available on day 1. That being said,  perhaps Rosetta 2 will run the JDK/JRE 
until a proper port is available. I don’t know if the JIT compiler will work 
with Rosetta though. If it doesn’t then that certainly makes a proper port more 
urgent. 


Scott

> On Jul 1, 2020, at 2:13 PM, Danny Gonzalez 
>  wrote:
> 
> Hi All,
> 
> Not sure if this is the correct place to direct this conversation but here 
> goes.
> 
> With the imminent arrival of Arm Macs in late 2020 running MacOS Big Sur, 
> what are the plans to ensure that OpenJFX and Java will run on this platform?
> 
> Are there plans to get the Developer Transition Kit to test on real hardware 
> prior to the release of consumer hardware?
> Are there testers testing on MacOs beta?
> 
> Will OpenJFX and Java be able to run natively in this new Arm Mac environment?
> Will OpenJFX and Java be able to run in the Rosetta emulator?
> 
> We have many MacOS customers, many of whom will be early adopters and upgrade 
> to the new Arm Macs so this could be a big issue for us.
> 
> Thanks
> 
> Danny
> 
> 


Re: Font rendering issue on macOS - cut off characters

2020-05-25 Thread Scott Palmer
> Can anyone say if they definitely see it on a built-in retina display too ?

Yes. It is present on the built-in Retina display on my mid-2015 MacBook Pro 
running Catalina 10.15.5 beta. 

I looked quickly using Java 8.

Scott


> On May 25, 2020, at 2:48 PM, Philip Race  wrote:
> 
> Mmm .. it can't be the same bug even if the effect is similar.
> We don't use freetype on macOS, that's for Linux.
> 
> Can you check your display's settings ?
> 
> https://spin.atomicobject.com/2018/08/24/macbook-pro-external-monitor-display-problem/
> 
> I have a Dell U2412M and it has a menu similar to what he sees and macOS for 
> me defaults to RGB,
> and selecting YPbYr results in a LOT more problems than text because I don't 
> think macOS is
> changing the signal when I do - I am connected via displayport too FWIW but 
> have an old mac (2015)
> and an old OS (10.13.6),
> 
> BTW I found the incident (bug report) and I see it is submitted as an FX 
> regression
> in 14.0.1 when I haven't seen any reason to suggest this is the case.
> Isn't everyone seeing it just when they move to catalina ?
> 
> Can anyone say if they definitely see it on a built-in retina display too ?
> 
> You might also want to check what color profile is set in System settings -> 
> Display -> Color.
> 
> -phil.
> 
> 
>> On 5/25/20, 9:44 AM, John Neffenger wrote:
>>> On 5/24/20 4:27 PM, Rob Nikander wrote:
>>> You can see the shaved “o” characters there, but I’m just talking about the 
>>> colors now. Is that normal?
>> 
>> No. I think it's a bug.
>> 
>> See my comment dated May 20, 2020, on the old GitHub issue that reported the 
>> same bug on Linux in 2018 and was fixed for JavaFX 12.
>> 
>> Yes, it does look as if macOS now has the same problem ...
>> https://github.com/javafxports/openjdk-jfx/issues/229#issuecomment-631797333 
>> 
>> Dirk Lemmermann opened a new bug report, but I don't know the JDK Bug System 
>> number yet. I would like see whether I can come up with a fix, but I can't 
>> say when I'll get to it.
>> 
>> John


Re: Windows Installation Instructions, All DLL Files Missing

2020-04-17 Thread Scott Palmer
I use jlink and jpackage to distribute JavaFX applications.
You suggest there will be a problem if you use jlink, but it will work if you 
include the needed javafx modules. The .jmod files contain the necessary native 
libraries and jlink will build a JRE that has the DLLs in the right place for 
the runtime to find them.

Modifying your PATH is not the right way to do this. Distributing a runtime 
with your application is the right way to solve this. The jlink and jpackage 
tools make this fairly easy.  I use a custom Gradle script to bundle my 
application, it works well.

Scott

> On Apr 17, 2020, at 2:55 PM, Christopher Miles  wrote:
> 
> I manage a project[0]  that leverages JavaFX. It's been a while since I've 
> worked on this project, almost two years. At that time JavaFX was bundled 
> with the Java runtime from Oracle. The few customers I had would simply run 
> the application from the bundled launcher and as long as they had Java 
> installed, it would work.
> 
> It's time for me to add some features to the project, I am now using OpenJDK 
> 14.0.1 and I installed the OpenJavaFX package and followed the 
> instructions[1] from the following URL:
> 
> https://openjfx.io/openjfx-docs/#install-javafx
> 
> I am on Windows and followed the instructions for that platform. 
> Unfortunately, things didn't really work. The error was as follows:
> 
> Graphics Device initialization failed for : d3d, sw Error initializing 
> QuantumRenderer: no suitable pipeline found java.lang.RuntimeException: 
> java.lang.RuntimeException: Error initializing QuantumRend erer: no suitable 
> pipeline found at 
> javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(Unkno 
> wn Source)
> 
> I fussed with this and that but nothing made a difference. Eventually I tried 
> adding the "bin" directory from the JavaFX distribution to my path. This is 
> the entry I added to my global PATH variable:
> 
> C:\Program Files\Java\javafx-sdk-14\bin
> 
> Is this the right way to do this and, if so, why isn't this included in the 
> directions? Is this a Windows specific issue?
> 
> Also, what impact does this have on distribution of applications?
> 
> Looking at the "Runtime Images" instructions, it looks like the same issues 
> will be present. Those instructions use `jlink` to point to the JavaFX 
> libraries and the JAVAFX modules (distributed in another package) but also 
> leave off references to the DLL files in the "bin" directory. I am worried 
> that I will need to have people manually install the OpenJavaFX distribution 
> and add the "bin" directory to their path in order to run my application. 
> Please say it's not so!
> 
> Any help or pointers to additional documentation would be very much 
> appreciated! I have made it over the bumps and can now continue development 
> of my application, my next concern is distributing it to customers.
> 
> -- 
> Miles
> 
> [0]: https://github.com/cmiles74/xmltool
> [1]: https://openjfx.io/openjfx-docs/#install-javafx



Re: Alternatives for JDK-8185886: Improve scrolling performance of TableView and TreeTableView

2020-04-03 Thread Scott Palmer
Assuming testing and performance/memory analysis leads to the conclusion that 
the risks are worth it, would it make sense to do both? Would we get a greater 
benefit from the combined effects? Or is the incremental improvement of 
including the second fix (whichever it may be) no longer significant enough to 
bother with?


Scott

> On Apr 3, 2020, at 2:15 PM, Kevin Rushforth  
> wrote:
> 
> We now have two pull requests under review that propose to solve the poor 
> scrolling performance of TableView and TreeTableView, as tracked by 
> JDK-8185886 [1]
> 
> The first one, PR #108 [2], proposes a change in the bindings 
> ExpressionHelper code relating to the cleaning up of listeners (changing the 
> array-based implementation to a Map). It is a change in javafx.base to make 
> the existing operations that TableView / TreeTableView do less expensive.
> 
> The second one, PR #125 [3], proposes to address the problem by eliminating 
> the need for cleaning up a large numbers of bindings. This approach changes 
> the javafx.controls code used by TableView, and doesn't touch the binding 
> code.
> 
> It would be helpful to discuss which approach to take on this list, so we 
> aren't independently reviewing both PRs.
> 
> I don't yet have an opinion on which way to go, but I will note a couple pros 
> / cons of each approach.
> 
> PR #108 is both a more fundamental change and a simpler change. It changes 
> the characteristics (memory footprint, performance) of a class that is used 
> by far more that just TableView and TreeTableView. This is both a potential 
> benefit and risk. If done in such a way that there are no regressions 
> (functional, memory, or performance), it could benefit more than just the 
> scrolling issue in question. By contrast, it has the potential to impact 
> other use cases negatively, mainly from a performance or memory point of 
> view, since the logic changes are relatively simple, and should be largely 
> "behavior neutral".
> 
> PR #125 is a more targeted change, impacting only the two controls in 
> question, but is a more complicated change from a logic point of view. I am 
> concerned primarily with any unintended behavioral changes.
> 
> Both of them will need to be very well tested to ensure that there are no 
> regressions.
> 
> -- Kevin
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8185886
> [2] https://github.com/openjdk/jfx/pull/108
> [3] https://github.com/openjdk/jfx/pull/125
> 


Re: Seeking help with latest master ...

2020-03-31 Thread Scott Palmer
> Could not resolve all dependencies for configuration ':apps:lucene'.
  > Multiple build operations failed.
java.lang.ExceptionInInitializerError
java.lang.NoClassDefFoundError: Could not initialize class
   sun.security.ssl.SSLContextImpl$TLSContext
java.lang.NoClassDefFoundError: Could not initialize class
   sun.security.ssl.SSLContextImpl$TLSContext
 > java.lang.ExceptionInInitializerError
 > java.lang.NoClassDefFoundError: Could not initialize class
   sun.security.ssl.SSLContextImpl$TLSContext
 > java.lang.NoClassDefFoundError: Could not initialize class
   sun.security.ssl.SSLContextImpl$TLSContext


This to me looks like it may be failing to make an https connection to a 
repository when attempting to download dependencies.

There are reports of NoClassDefFoundError w.r.t. SSLContextImpl when running 
gradle builds, see: 
https://github.com/gradle/gradle/issues/7842 


Claims to be fixed, but maybe not?

If it is related to Gradle changing java.home while compiling, I wonder if 
using --no-parallel might work around it?  Of course try with --debug as well 
to see if it offers more clues.

Regards,

Scott

> On Mar 31, 2020, at 1:21 PM, Rony G. Flatscher  
> wrote:
> 
> On 31.03.2020 19:10, Kevin Rushforth wrote:
>> That's not the problem. The minimum build number only applies if at the 
>> exact minimum JDK version
>> in question. You are using 11.0.6 which is > 11 so no problem there.
>> 
>> One last thing to try:
>> 
>> $ rm -rf .gradle buildSrc/.gradle buildSrc/build
>> 
>> In case something is cached there that the newer gradle trips over.
> 
> Unfortunately did not resolve the failure:
> 
>rony@rony-linux:~/dev/github/openjdk/jfx$ rm -rf build .gradle 
> buildSrc/.gradle buildSrc/build
>rony@rony-linux:~/dev/github/openjdk/jfx$ gradle --stop
>No Gradle daemons are running.
>rony@rony-linux:~/dev/github/openjdk/jfx$ gradle clean
>Starting a Gradle Daemon, 5 stopped Daemons could not be reused, use 
> --status for details
> 
>> Configure project :
>gradle.gradleVersion: 6.3
>OS_NAME: linux
>OS_ARCH: amd64
>JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64
>JDK_HOME: /usr/lib/jvm/java-11-openjdk-amd64
>java.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
>java version: 11.0.6
>java build number: 10
>jdk.runtime.version: 11.0.6+10-post-Ubuntu-1ubuntu118.04.1
>jdk version: 11.0.6
>jdk build number: 10
>minimum jdk version: 11
>minimum jdk build number: 28
>GCC version: gcc8.3.0-OL6.4+1.0
>cmake version: 3.13.3
>ninja version: 1.8.2
>ant version: 1.10.5
>HAS_JAVAFX_MODULES: false
>STUB_RUNTIME: /usr/lib/jvm/java-11-openjdk-amd64
>CONF: Debug
>NUM_COMPILE_THREADS: 8
>COMPILE_TARGETS: linux
>COMPILE_FLAGS_FILES: buildSrc/linux.gradle
>HUDSON_JOB_NAME: not_hudson
>HUDSON_BUILD_NUMBER: 
>PROMOTED_BUILD_NUMBER: 0
>PRODUCT_NAME: OpenJFX
>RELEASE_VERSION: 15
>RELEASE_SUFFIX: -internal
>RELEASE_VERSION_SHORT: 15-internal
>RELEASE_VERSION_LONG: 15-internal+0-2020-03-31-191843
>RELEASE_VERSION_PADDED: 15.0.0.0
>MAVEN_VERSION: 15-internal+0-2020-03-31-191843
>UPDATE_STUB_CACHE: false
>Building Webkit configuration /Release/ into
>/home/rony/dev/github/openjdk/jfx/modules/javafx.web/build/linux
>module: project ':apps' (buildModule=NO)
>module: project ':base' (buildModule=YES)
>module: project ':controls' (buildModule=YES)
>module: project ':fxml' (buildModule=YES)
>module: project ':graphics' (buildModule=YES)
>module: project ':media' (buildModule=YES)
>module: project ':swing' (buildModule=YES)
>module: project ':swt' (buildModule=NO)
>module: project ':systemTests' (buildModule=NO)
>module: project ':web' (buildModule=YES)
> 
>FAILURE: Build completed with 2 failures.
> 
>1: Task failed with an exception.
>---
>* Where:
>Build file '/home/rony/dev/github/openjdk/jfx/build.gradle' line: 4176
> 
>* What went wrong:
>A problem occurred evaluating root project 'jfx'.
>> Could not resolve all dependencies for configuration ':apps:lucene'.
>   > Multiple build operations failed.
> java.lang.ExceptionInInitializerError
> java.lang.NoClassDefFoundError: Could not initialize class
>sun.security.ssl.SSLContextImpl$TLSContext
> java.lang.NoClassDefFoundError: Could not initialize class
>sun.security.ssl.SSLContextImpl$TLSContext
>  > java.lang.ExceptionInInitializerError
>  > java.lang.NoClassDefFoundError: Could not initialize class
>sun.security.ssl.SSLContextImpl$TLSContext
>  > java.lang.NoClassDefFoundError: Could not initialize class
>sun.security.ssl.SSLContextImpl$TLSContext
> 
>* Try:
>Run with --stacktrace option to get the stack trace. Run with --info or 
> --debug 

Re: RFR: 8236753: Animations do not play backwards after being stopped

2020-01-14 Thread Scott Palmer



> On Jan 14, 2020, at 11:50 AM, Ambarish Rapte  wrote:
> 
> On Fri, 10 Jan 2020 00:39:53 GMT, Kevin Rushforth  wrote:
> 
>>> I'll review this next week. This seems a fine candidate for openjfx14, so 
>>> it (along with a couple other pending reviews that can be for 14) will be a 
>>> good test of targeting a PR to the stabilization branch.
>>> 
>>> I also request @arapte to review.
>> 
>> I should add that it will depend on whether there are any regressions. One 
>> thing we do need to be careful of is introducing regressions during rampdown.
> 
> The fix looks good to me.
> After this change the steps needed for playing an `Animation` backwards will 
> change.
> Earlier this was documented with `Animation.play()` API as below.
> -
> To play an `Animation` backwards from the end:
> animation.setRate(negative rate);
> animation.jumpTo(overall duration of animation);
> animation.play();
> -
> 
> After this PR call to `jumpTo()` won't be needed here.
> So this PR may need a document change for `Animation.play()`.
> Also to note that the behavior of above mentioned three calls remains same 
> with the changes in this change.

If the jumpTo isn’t required, then this isn’t this a change in behaviour?  I’m 
wonder in particular if this has an effect on cycleCount.

If cycleCount is set to 2 does the animation play the same number of times with 
or without the jumpTo both before and after this change?

Scott

RFR: 8236648: javadoc warning on Text::tabSizeProperty method

2020-01-06 Thread Scott Palmer
Implemented suggested fix to address javadoc warning.

-

Commits:
 - bd81a902: 8236648: javadoc warning on Text::tabSizeProperty method

Changes: https://git.openjdk.java.net/jfx/pull/78/files
 Webrev: https://webrevs.openjdk.java.net/jfx/78/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8236648
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jfx/pull/78.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/78/head:pull/78

PR: https://git.openjdk.java.net/jfx/pull/78


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-21 Thread Scott Palmer
On Sat, 21 Dec 2019 03:03:57 GMT, Scott Palmer  wrote:

>> Interesting.  I was only running the tests in graphics (gradle 
>> :graphics:test) as when I run all the tests I always get this failure 
>> (unrelated to anything I've changed):
>> 
>>> Task :base:test
>> 
>> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
>> toString_to_fromString_testRoundtrip[0] FAILED
>> java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' 
>> could not be parsed, unparsed text found at index 19
>> at 
>> java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
>> at 
>> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
>> at 
>> javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
>> at 
>> javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
>> at 
>> test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)
>> 
>> 5222 tests completed, 1 failed, 27 skipped
> 
> I'm not sure if I'me supposed to try to integrate now that I've made that 10 
> -> 0 change, or if the new change resets the need for review... Also, note 
> that the link in the bot msg for "project specific requirements" is giving me 
> a 404 error.

Link problem appears to just be a missing slash: 
https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-20 Thread Scott Palmer
On Sat, 21 Dec 2019 02:50:54 GMT, Scott Palmer  wrote:

>> The fix looks good now. There is one problem in the test (in 
>> `StubTextLayout`) that needs to be fixed.
> 
> Interesting.  I was only running the tests in graphics (gradle 
> :graphics:test) as when I run all the tests I always get this failure 
> (unrelated to anything I've changed):
> 
>> Task :base:test
> 
> test.javafx.util.converter.LocalDateTimeStringConverterTest > 
> toString_to_fromString_testRoundtrip[0] FAILED
> java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' 
> could not be parsed, unparsed text found at index 19
> at 
> java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
> at 
> java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
> at 
> javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
> at 
> javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
> at 
> test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)
> 
> 5222 tests completed, 1 failed, 27 skipped

I'm not sure if I'me supposed to try to integrate now that I've made that 10 -> 
0 change, or if the new change resets the need for review... Also, note that 
the link in the bot msg for "project specific requirements" is giving me a 404 
error.

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 06] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-20 Thread Scott Palmer
> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to 
> both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-

Added commits:
 - 78ddf12e: 8130738: Fixed test issue with StubTextLayout

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/f846ad6d..78ddf12e

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.06
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-20 Thread Scott Palmer
On Fri, 20 Dec 2019 23:43:53 GMT, Kevin Rushforth  wrote:

>> The pull request has been updated with 1 additional commit.
> 
> The fix looks good now. There is one problem in the test (in 
> `StubTextLayout`) that needs to be fixed.

Interesting.  I was only running the tests in graphics (gradle :graphics:test) 
as when I run all the tests I always get this failure (unrelated to anything 
I've changed):

> Task :base:test

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
toString_to_fromString_testRoundtrip[0] FAILED
java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' 
could not be parsed, unparsed text found at index 19
at 
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
at 
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
at 
javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
at 
javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)

5222 tests completed, 1 failed, 27 skipped

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-20 Thread Scott Palmer
On Fri, 20 Dec 2019 00:19:43 GMT, Kevin Rushforth  wrote:

>> I was thinking of deferring the `apps/toys` demo to avoid any delays in 
>> getting the new API into JavaFX 14.  I have something for it, I just don't 
>> want any feedback on it to hold up the review of this issue. Is there 
>> anything else I need to do?  Is the CSR in good shape?
> 
> I agree that that addition of a demo program in `apps/toys` can be decoupled 
> from this. Please file a follow-up issue for this.
> 
> I reviewed the CSR. It looks ready to go.
> 
> In addition to an approved CSR, both @prrace and I will need to review this 
> PR.

I have created https://bugs.openjdk.java.net/browse/JDK-8236438 to track the 
creation of a demo program.

-

PR: https://git.openjdk.java.net/jfx/pull/32


apps/toys HelloTextFlow renders incorrectly on macOS 10.15

2019-12-19 Thread Scott Palmer
As follow up to JDK-8130738 I was thinking about adding a new panel to 
HelloTextFlow to show adjusting the tabSize rather than making a new ‘toy’.  
However I noticed rendering issues right away.  When you select text, parts of 
the text seem to paint white-on-white .. proportional to the amount selected.  
Try it on macOS 10.15 and hopefully you will see what I mean. I’ve attached a 
couple screenshots if they make it through to the list…

Is this a known issue?

Scott



Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-19 Thread Scott Palmer
On Thu, 12 Dec 2019 21:51:56 GMT, Nir Lisker  wrote:

>> The pull request has been updated with 1 additional commit.
> 
> 

I was thinking of deferring the `apps/toys` demo to avoid any delays in getting 
the new API into JavaFX 14.  I have something for it, I just don't want any 
feedback on it to hold up the review of this issue. Is there anything else I 
need to do?  Is the CSR in good shape?

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: Skara - bot sending can-be-integrated message prematurely?

2019-12-17 Thread Scott Palmer
Perhaps the language in the message should be tweaked?
Maybe use, “This change can be integrated if there are no further review 
requirements.“

Scott

> On Dec 17, 2019, at 4:57 PM, Kevin Rushforth  
> wrote:
> 
> Yes, other projects have multiple review requirements. And similar to 
> JavaFX, the answer to how many reviewers are needed is "it depends"; 
> sometimes one is enough for certain sub-projects or simple fixes; other 
> sub-projects want two reviewers; sometimes you want a specific expert to 
> review a tricky change in one area being touched by a fix in addition to the 
> two primary reviewers.
> 
> I think if Skara tries to get into the business of covering all cases, we 
> will be adding a lot of complexity and still not be satisfied. The current 
> approach, which I think is the right one for now, is to for the tool to 
> enforce the minimum requirement for any fix to be integrated. Beyond that it 
> is up to the Committer and Reviewer(s) to make sure that the all criteria for 
> integrating a fix have been met.
> 
> -- Kevin
> 
> 
>> On 12/16/2019 4:14 PM, Nir Lisker wrote:
>> Do other projects also have multi-reviewers requirements?
>> 
>> I would think that at least for a CSR, which is OpenJDK-wide, a request 
>> could be put in with the Skara to track it. A Reviewer (or Committer?) could 
>> invoke a /csr command which will require the PR author to provide a link to 
>> the CSR, and check that it was approved as part of the patch approval 
>> process.
>> 
>> Not sure how complicated it would be to implement.
>> 
>> - Nir
>> 
>> On Mon, Dec 16, 2019 at 5:39 PM Kevin Rushforth > > wrote:
>> 
>>That's a good question about whether we can ask for a slight
>>rewording
>>of the Skara bot message to indicate that there might be other
>>things to
>>check before "/integrate". I'll raise that question with the Skara
>>team.
>> 
>>As an aside, I noticed the other day that you typed "/integrate"
>>after a
>>single review, but in that case, there was no clear indication
>>from Ajit
>>(the first reviewer and the sponsor) that a second review was
>>required,
>>so I didn't comment on it.
>> 
>>-- Kevin
>> 
>> 
>>On 12/16/2019 6:41 AM, Jeanette Winzenburg wrote:
>>>
>>> Kevin,
>>>
>>> thanks for the clarification :) My bad that I didn't re-read the
>>> contrib.md. But then, who does? The lazy like myself do it
>>> occasionally only (down to once and then forget about it )
>>>
>>> Maybe the bot message can be improved? With some indication that
>>its
>>> (the bot's) knowledge about review requirements is limited, so
>>would
>>> require a careful check by the contributor before actually post the
>>> /integrate comment? Actually, I think I goofed the other day, was
>>> safed only by Ajit who waited for the 2nd review before his
>>/sponsor.
>>>
>>> -- Jeanette
>>>
>>> Zitat von Kevin Rushforth >>:
>>>
>>>> I added a comment to the two PRs in question, but it bears
>>discussion
>>>> here.
>>>>
>>>> The Skara bot can't know whether all criteria have been met. It
>>>> can't, for example, know whether there are outstanding comments
>>from
>>>> some reviewers that need to be addressed. Nor does it know
>>which PRs
>>>> need two reviewers (or sometimes a third if there is a specific
>>>> person we would like to review it), which ones need a CSR, etc.
>>>>
>>>> So having it state authoritatively that the PR is ready to
>>integrate
>>>> is a bit misleading. This is documented in the Code Review
>>section of
>>>> the CONTRIBUTING [1] doc:
>>>>
>>>>> NOTE: while the Skara tooling will indicate that the PR is
>>ready to
>>>>> integrate once the first reviewer with a "Reviewer" role in the
>>>>> project has approved it, this may or may not be sufficient
>>depending
>>>>> on the type of fix. For example, you must wait for a second
>>approval
>>>>> for enhancements or high-impact bug fixes.
>>>>
>>>> If anyone can think of a way to improve this and make it more
>>clear,
>>>> that would be helpful.
>>>>
>>>> -- Kevin
>>>>
>>>> [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md
>>>>
>>>>
>>>> On 12/16/2019 4:23 AM, Jeanette Winzenburg wrote:
>>>>>
>>>>> Looks like it assumes a pull request as properly reviewed as
>>soon as
>>>>> it gets a single approve - independent on how many reviewers are
>>>>> required, see f.i.
>>>>>
>>>>> https://github.com/openjdk/jfx/pull/15#issuecomment-565964995
>>>>> https://github.com/openjdk/jfx/pull/6#issuecomment-566028296
>>>>>
>>>>> -- Jeanette
>>>>>
>>>
>>>
>>>
>> 
> 


Re: [Rev 05] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-14 Thread Scott Palmer
> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to 
> both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-

Added commits:
 - f846ad6d: 8130738: Add tabSize property to Text and TextFlow

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/f99a3aa9..f846ad6d

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.05
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.04-05

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-14 Thread Scott Palmer
On Sat, 14 Dec 2019 16:38:25 GMT, Kevin Rushforth  wrote:

>> TextFlow isn't mentioned in the JavaDoc for any of the other Text properties 
>> where the same rule applies.  Perhaps that should be remedied with a 
>> follow-up task?
> 
> A follow-up issue would be fine.

I've created https://bugs.openjdk.java.net/browse/JDK-8235958 as a follow-up 
javadoc enhancement.

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Fri, 13 Dec 2019 01:29:47 GMT, Phil Race  wrote:

>> The terms "tab character" or "horizontal tab" refer to the ASCII tab 
>> character itself. Since a tab character isn't a fixed number of spaces, 
>> changing it to "size of a tab character" could be misleading. I'd be fine 
>> with another alternative, though, if someone could come up with a better one.
> 
> We are referring to the character here aren't we ? ie the actual character 
> and the rest of it is about how it renders.
> Paraphrasing the java doc it says :
> If you display  it will display as N instances of  space character>

I find "size of the tab character" to be a bit confusing.  The number of space 
you advance is not a constant for one, so tab characters don't really have a 
fixed size in that sense.  The javadoc could be rephrased as "the distance 
between tab stops".  However, that keeps the unfamiliar, but correct IMO, "tab 
stop" wording.  For the record the top google hit for "tab stop" results in: "A 
tab stop is a term used to describe the location the cursor stops after the Tab 
key is pressed." Wikipedia says something similar and adds, "In text editors on 
a computer, the same concept is implemented simplistically with automatic, 
fixed tab stops."

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Thu, 12 Dec 2019 22:02:14 GMT, Nir Lisker  wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/TextFlow.java line 
> 494:
> 
>> 493:  * Values less than 1 are treated as 1. This value overrides the
>> 494:  * {@code tabSize} of contained {@link javafx.scene.text.Text Text} 
>> nodes.
>> 495:  *
> 
> `{@link Text}` is enough, but the FQN is also fine.
> 
> Does `Text`'s `tabSize` need a note that its value is overriden if the text 
> is contained in a `TextFlow`?

TextFlow isn't mentioned in the JavaDoc for any of the other Text properties 
where the same rule applies.  Perhaps that should be remedied with a follow-up 
task?

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Thu, 12 Dec 2019 21:41:12 GMT, Nir Lisker  wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1883:
> 
>> 1882: }
>> 1883: @Override protected void invalidated() {
>> 1884: TextLayout layout = getTextLayout();
> 
> I think that annotations tend to go on a line above what they annotate,

I'm following the pattern established elsewhere in the file for other property 
overrides. (underline, strikethrough, textAlignment, selectionEnd, etc.).  I 
would keep this for consistency and compactness, unless there are more votes 
against it.

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Thu, 12 Dec 2019 21:29:06 GMT, Nir Lisker  wrote:

>> The pull request has been updated with 1 additional commit.
> 
> modules/javafx.graphics/src/main/java/javafx/scene/text/Text.java line 1450:
> 
>> 1449: private static final CssMetaData TAB_SIZE =
>> 1450: new CssMetaData("-fx-tab-size",
>> 1451: SizeConverter.getInstance(), 
>> TextLayout.DEFAULT_TAB_SIZE) {
> 
> I think that type parameters should have space separation after a comma: 
> `Text, Number`, though I've seen without too.

Most of the instances where CssMetaData is used in the rest of the file don't 
have a space. The exceptions seem to be where there is a wildcard in the type 
parameter.  It could be left as-is simply to maintain consistency within the 
file.  Though I tend to agree that a space makes sense.

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Thu, 12 Dec 2019 19:48:37 GMT, Scott Palmer  wrote:

>> In that case, I recommend just doing the API get/set tests for `TextFlow` 
>> without creating a `Scene` or `Stage`. This won't need anything from the 
>> `StubToolkit`.
> 
> In my attempts to address the issue with StubTextLayout I discovered bugs.  
> TextFlow is NOT properly overriding the tabSize of the Text nodes.  If you 
> set the Text node tab size later, the layout reacts and adjusts to the 
> tabSize of the Text node even though it is contained in a TextFlow.  
> Whichever node changes the tabSize last affects the layout.   I'm going to 
> have to study this more, but this change isn't ready at this point.

Looks like I was missing a check for isSpan() in the invalidated method of the 
tabSize property of Text.  I've fixed StubTextLayout to work with TextFlow now.

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 04] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to 
> both.  TextFlow's tab size overrides that of contained Text nodes.

The pull request has been updated with 1 additional commit.

-

Added commits:
 - f99a3aa9: 8130738: Add tabSize property to Text and TextFlow

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/af959665..f99a3aa9

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.04
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.03-04

  Stats: 170 lines in 6 files changed: 147 ins; 9 del; 14 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-12 Thread Scott Palmer
On Wed, 11 Dec 2019 01:22:54 GMT, Kevin Rushforth  wrote:

>> The unit tests that were already added to `TextTest.java` cover the new 
>> methods on Text, but not in every combination.  I'll add a couple more to 
>> ensure all combinations are covered. `TextFlow` has no existing unit tests 
>> that I could find!  Shall I add a new `TextFlowText.java` file for just 
>> these tests?
>> 
>> The apps/toys folder seems to use ant-based projects.  The existing ones 
>> don't build for me. If I made a new project there could I use the JavaFX 
>> Gradle plugin and configure it to get JavaFX from the build/sdk folder?
> 
> I think a new `TextFlowTest.java` would be a good place for those tests.
> 
> Our build is set up to use `ant` so if you want to wire it up to the build, 
> you'll need that (it should be as simple as having `ANT_HOME` set to 
> `apache-ant-1.10.5`). It would be fine to defer this if you can't get it 
> working.

I just noticed while updating the CSR that, while I mentioned it on the mailing 
list, the fact that TextFlow's tabSize override that of any contained Text 
nodes is not documented.
Shall I add to the javadoc for tabSize  in TextFlow : "This value overrides the 
tabSize of contained Text nodes." ?

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-11 Thread Scott Palmer



> On Dec 10, 2019, at 8:23 PM, Kevin Rushforth  wrote:
...
> 
> I think a new `TextFlowTest.java` would be a good place for those tests.

My first attempt at unit tests for TextFlow are failing.  I believe the 
StubTextLayout is not equipped to handle TextFlow.  This may be a bigger job…

This fragment triggers a NPE:
...
Toolkit tk = (StubToolkit) Toolkit.getToolkit();
HBox root = new HBox();
Scene scene = new Scene(root);
Stage stage = new Stage();
stage.setScene(scene);
stage.setWidth(300);
stage.setHeight(200);

try {
Text text1 = new Text("\tfirst");
Text text2 = new Text("\tsecond");
TextFlow textFlow = new TextFlow(text1, text2);
root.getChildren().addAll(textFlow);
stage.show();
...

test.javafx.scene.text.TextFlowTest > testTabSize FAILED
java.lang.NullPointerException
at 
test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:88)
at 
test.com.sun.javafx.pgstub.StubTextLayout.getBounds(StubTextLayout.java:82)
at 
javafx.graphics/javafx.scene.text.TextFlow.computePrefWidth(TextFlow.java:254)
at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
at 
javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
at 
javafx.graphics/javafx.scene.layout.Region.computeChildPrefAreaWidth(Region.java:1946)
at javafx.graphics/javafx.scene.layout.HBox.getAreaWidths(HBox.java:465)
at 
javafx.graphics/javafx.scene.layout.HBox.computeContentWidth(HBox.java:540)
at 
javafx.graphics/javafx.scene.layout.HBox.computePrefWidth(HBox.java:433)
at javafx.graphics/javafx.scene.Parent.prefWidth(Parent.java:1019)
at 
javafx.graphics/javafx.scene.layout.Region.prefWidth(Region.java:1543)
at javafx.graphics/javafx.scene.Scene.getPreferredWidth(Scene.java:1799)
at 
javafx.graphics/javafx.scene.Scene.resizeRootToPreferredSize(Scene.java:1779)
at javafx.graphics/javafx.scene.Scene.preferredSize(Scene.java:1747)
at javafx.graphics/javafx.scene.Scene$2.preferredSize(Scene.java:393)
at 
javafx.graphics/com.sun.javafx.scene.SceneHelper.preferredSize(SceneHelper.java:66)
at javafx.graphics/javafx.stage.Window$12.invalidated(Window.java:1086)
at 
javafx.base/javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at 
javafx.base/javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
at javafx.graphics/javafx.stage.Window.setShowing(Window.java:1174)
at javafx.graphics/javafx.stage.Window.show(Window.java:1189)
at javafx.graphics/javafx.stage.Stage.show(Stage.java:273)
at test.javafx.scene.text.TextFlowTest.testTabSize(TextFlowTest.java:60)


Scott



Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-12-10 Thread Scott Palmer
On Tue, 10 Dec 2019 23:51:48 GMT, Kevin Rushforth  wrote:

>>> Should this PR also add a tabSize property to controls such as TextArea? Or 
>>> should that be a different PR after this one is merged?
>> 
>> This would need to be a new enhancement and would first need to be discussed 
>> on the openjfx-dev mailing list. There are additional things to consider in 
>> order to support tab size for controls, and it isn't clear whether there is 
>> enough benefit in doing it.
> 
> As a follow-on point to the missing public method in TextFlow, can you add 
> unit tests for the API methods on both `Text` and `TextFlow`? A good way to 
> do that is to have a test for all combinations of setting the value via the 
> setter and the property method, and getting the value via the getter and the 
> property method.

The unit tests that were already added to `TextTest.java` cover the new methods 
on Text, but not in every combination.  I'll add a couple more to ensure all 
combinations are covered. `TextFlow` has no existing unit tests that I could 
find!  Shall I add a new `TextFlowText.java` file for just these tests?

The apps/toys folder seems to use ant-based projects.  The existing ones don't 
build for me. If I made a new project there could I use the JavaFX Gradle 
plugin and configure it to get JavaFX from the build/sdk folder?

-

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 03] RFR: 8130738: Add tabSize property to Text and TextFlow

2019-11-27 Thread Scott Palmer
The pull request has been updated with additional changes.



Added commits:
 - af959665: 8130738: Add tabSize property to Text and TextFlow

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/254c40de..af959665

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.03
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.02-03

  Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
  Stats: 57 lines in 6 files changed: 25 ins; 26 del; 6 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Re: RFR: 8130738: Add tabSize property to Text and TextFlow

2019-11-26 Thread Scott Palmer
On Tue, 26 Nov 2019 18:48:38 GMT, Kevin Rushforth  wrote:

> On Tue, 26 Nov 2019 18:40:10 GMT, Scott Palmer  wrote:
> 
>> On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth  wrote:
>> 
>>> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer  wrote:
>>> 
>>>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute 
>>>> to both.  TextFlow's tab size overrides that of contained Text nodes.
>>>> 
>>>> 
>>>> 
>>>> Commits:
>>>>  - 68d221c7: 8130738: TextFlow's tab width is static
>>>> 
>>>> Changes: https://git.openjdk.java.net/jfx/pull/32/files
>>>>  Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00
>>>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
>>>>   Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod
>>>>   Patch: https://git.openjdk.java.net/jfx/pull/32.diff
>>>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32
>>> 
>>>>  I should clamp so it reads back as 1 - Fixed.
>>> 
>>> This has implications for binding, etc., so I suspect this is not what we 
>>> want. I'll look into this more when I review it.
>>> 
>>> NOTE: This will need a CSR in addition to two reviewers. You can file the 
>>> CSR any time, but I suggest leaving it in Draft state until Phil and I have 
>>> had a first pass look at the API.
>> 
>> The indenting was wrong in that section and I had to make some minor 
>> changes, so I corrected the bad indenting.  Kevin indicated, "In your 
>> specific case, reformatting the methods in the StyleableProperties nested 
>> class that are adjacent to code you add or modify seems fine, as long as you 
>> only change the indentation and not the line wrapping."
>> 
>> I didn't intend to trigger an update to this pull request...I find Git 
>> awkward to work with (Mercurial makes more sense to me) so I'm making 
>> mistakes as I bumble around. 
>> 
>> I do expect an update to address the way I've clamped to 1.  I agree with 
>> Kevin that it is probable wrong. Just waiting for feedback.
> 
> I'll take a preliminary look today. I also plan to change the bug title to 
> make it more clear that it is an enhancement request, since it currently 
> reads like a bug report (I'll also change the CSR and PR title to match).

I just noticed that Text.toString is missing any indication of the tabSize.  
(Found by accident when I search for wrappingWidth to see how the javadocs were 
done.)
Is there any rule as to where in the order of properties ", tabSize = X" should 
be in the string?  I assume it should only be included when not set to the 
default value, much like lineSpacing?

PR: https://git.openjdk.java.net/jfx/pull/32


Re: RFR: 8130738: TextFlow's tab width is static

2019-11-26 Thread Scott Palmer
On Thu, 7 Nov 2019 14:56:58 GMT, Kevin Rushforth  wrote:

> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer  wrote:
> 
>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute 
>> to both.  TextFlow's tab size overrides that of contained Text nodes.
>> 
>> 
>> 
>> Commits:
>>  - 68d221c7: 8130738: TextFlow's tab width is static
>> 
>> Changes: https://git.openjdk.java.net/jfx/pull/32/files
>>  Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00
>>   Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
>>   Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod
>>   Patch: https://git.openjdk.java.net/jfx/pull/32.diff
>>   Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32
> 
>>  I should clamp so it reads back as 1 - Fixed.
> 
> This has implications for binding, etc., so I suspect this is not what we 
> want. I'll look into this more when I review it.
> 
> NOTE: This will need a CSR in addition to two reviewers. You can file the CSR 
> any time, but I suggest leaving it in Draft state until Phil and I have had a 
> first pass look at the API.

The indenting was wrong in that section and I had to make some minor changes, 
so I corrected the bad indenting.  Kevin indicated, "In your specific case, 
reformatting the methods in the StyleableProperties nested class that are 
adjacent to code you add or modify seems fine, as long as you only change the 
indentation and not the line wrapping."

I didn't intend to trigger an update to this pull request...I find Git awkward 
to work with (Mercurial makes more sense to me) so I'm making mistakes as I 
bumble around. 

I do expect an update to address the way I've clamped to 1.  I agree with Kevin 
that it is probable wrong. Just waiting for feedback.

PR: https://git.openjdk.java.net/jfx/pull/32


Re: [Rev 02] RFR: 8130738: TextFlow's tab width is static

2019-11-26 Thread Scott Palmer
The pull request has been updated with a complete new set of changes (possibly 
due to a rebase).



Commits:
 - 254c40de: Merge remote-tracking branch 'upstream/master'
 - a670c4f8: 8130738: TextFlow's tab width is static
 - 68d221c7: 8130738: TextFlow's tab width is static

Changes: https://git.openjdk.java.net/jfx/pull/32/files
 Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.02
  Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
  Stats: 325 lines in 8 files changed: 261 ins; 0 del; 64 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Typo in native-glass/win/OleUtils.h checkJavaException

2019-11-20 Thread Scott Palmer
I discovered this by accident while trying to figure out where a certain
console message was coming from while debugging.

I saw this printed to the console when testing my (broken) code:

Java Messsge:com/openalpr/jni/AlprException

Note the typo in "Messsge" (the class name that follows is specific to what
I was testing).

I couldn't find the string "Java Messsge" in any of my code or the library
I was trying out (OpenALPR).  Eventually I found it was in glass.dll and
traced it to the checkJavaException function in OleUtils.h, line 230.

On another note, I see that function is declared as "inline", though I
suspect the body of the "else" really doesn't need to be inlined and the
extra size it adds to the method could make it less likely to actually get
inlined. It seems the part that you want inlined is the if
(!env-ExceptionCheck()) { return S_OK; }. Wouldn't the rest run very rarely
and not benefit from being inlined?  If that code does get inlined it would
bloat the code unnecessarily.  The premature optimizer in me (it's an evil
I have trouble controlling) thinks this just makes stuff less
cache-friendly.  I would put it in another not-inlined method.  Also note
that using "else" is redundant.


Scott


Re: RFR: 8130738: TextFlow's tab width is static

2019-11-07 Thread Scott Palmer
Yes, I suppose this should behave like anything else that uses an
IntegerProperty as far as bindings are concerned.  I'll wait for further
review before reverting that last change. If tabSize=0 worked reasonably it
would be much simpler.  I'm not sure if I will have the time to hunt down
why things go wrong in that case (everything after a tab appears at x
offset 0).

I've created the CSR, hopefully I did it correctly.
https://bugs.openjdk.java.net/browse/JDK-8233810

Scott

On Thu, Nov 7, 2019 at 9:57 AM Kevin Rushforth  wrote:

> On Wed, 6 Nov 2019 19:11:48 GMT, Scott Palmer 
> wrote:
>
> > Added tabSize property to Text and TextFlow and -fx-tab-size CSS
> attribute to both.  TextFlow's tab size overrides that of contained Text
> nodes.
> >
> > 
> >
> > Commits:
> >  - 68d221c7: 8130738: TextFlow's tab width is static
> >
> > Changes: https://git.openjdk.java.net/jfx/pull/32/files
> >  Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00
> >   Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
> >   Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod
> >   Patch: https://git.openjdk.java.net/jfx/pull/32.diff
> >   Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32
>
> >  I should clamp so it reads back as 1 - Fixed.
>
> This has implications for binding, etc., so I suspect this is not what we
> want. I'll look into this more when I review it.
>
> NOTE: This will need a CSR in addition to two reviewers. You can file the
> CSR any time, but I suggest leaving it in Draft state until Phil and I have
> had a first pass look at the API.
>
> PR: https://git.openjdk.java.net/jfx/pull/32
>


Re: RFR: 8130738: TextFlow's tab width is static

2019-11-07 Thread Scott Palmer
setValue(null) is interpreted as set(0) by IntegerProperty.  This in turn will 
be clamped to 1 by the TextLayout.  The property on the Text node will still 
read as 0.
So now that you mention it, I don’t like where the clamping is implemented.  I 
should clamp so it reads back as 1 - Fixed.

Scott

> On Nov 6, 2019, at 11:23 PM, David Grieve  wrote:
> 
> What happens if you do text.tabSizeProperty().setValue(null) ? 
> 
>> -Original Message-
>> From: openjfx-dev  On Behalf Of
>> Scott Palmer
>> Sent: Wednesday, November 6, 2019 11:12 AM
>> To: openjfx-dev@openjdk.java.net
>> Subject: RFR: 8130738: TextFlow's tab width is static
>> 
>> Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to
>> both.  TextFlow's tab size overrides that of contained Text nodes.



Re: [Rev 01] RFR: 8130738: TextFlow's tab width is static

2019-11-07 Thread Scott Palmer
The pull request has been updated with additional changes.



Added commits:
 - a670c4f8: 8130738: TextFlow's tab width is static

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/32/files
  - new: https://git.openjdk.java.net/jfx/pull/32/files/68d221c7..a670c4f8

Webrevs:
 - full: https://webrevs.openjdk.java.net/jfx/32/webrev.01
 - incr: https://webrevs.openjdk.java.net/jfx/32/webrev.00-01

  Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
  Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


RFR: 8130738: TextFlow's tab width is static

2019-11-06 Thread Scott Palmer
Added tabSize property to Text and TextFlow and -fx-tab-size CSS attribute to 
both.  TextFlow's tab size overrides that of contained Text nodes.



Commits:
 - 68d221c7: 8130738: TextFlow's tab width is static

Changes: https://git.openjdk.java.net/jfx/pull/32/files
 Webrev: https://webrevs.openjdk.java.net/jfx/32/webrev.00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8130738
  Stats: 324 lines in 8 files changed: 260 ins; 0 del; 64 mod
  Patch: https://git.openjdk.java.net/jfx/pull/32.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/32/head:pull/32

PR: https://git.openjdk.java.net/jfx/pull/32


Re: JDK-8130738 TextFlow's tab width is static

2019-11-05 Thread Scott Palmer
I finally had a moment to get back at this.

I've changed the name of the property from tabWidth to tabSize and
implemented the CSS property '-fx-tab-size'.  The CSS documentation will
need to be updated. I didn't see where the CSS document is located in the
source tree.

While adding CSS support I noticed that in both Text.java and TextFlow.java
the indentation is wrong for the StyleableProperties nested class (has one
extra space).  I wasn't sure how much I should change in the scope of this
feature.  If I don't fix some indenting my changes will look funny beside
the lines of existing code.  If I fix all of the broken indenting I'll
change a lot of lines that have nothing to do with this feature.  If I just
properly indent the lines I change or add, the indenting will be more
chaotic than it is currently.

I have noticed a rendering anomaly with a tab size of zero (the value I was
initially clamping to) and rather than dealing with that I took the easy
way out and changed it to agree with the minimum of 1 that Kevin indicated
for the range.

I have not limited the maximum tab size.  I know Phil has expressed that
MAXINT is not his preference, but I can't think of a good criteria for what
the maximum should be.  I can imagine someone using a tab separator to
align columns of text that have much more than 16 characters for example.
I did a quick test with the tab size set to Integer.MAX_VALUE-1 and nothing
blew up.  Of course the text after the tab was nowhere to be seen.


Regards,

Scott


On Thu, Oct 17, 2019 at 3:42 PM Phil Race  wrote:

>
>
> On 10/17/19 12:32 PM, Kevin Rushforth wrote:
> > It seems that you have a path forward then. So, there are a couple
> > questions to answer:
> >
> > 1. Should the type of the property be int or double? If it really is
> > only ever going to be a number of spaces, then int seems fine. That,
> > along with the name of the property, would underscore the fact that
> > no, this isn't a size where units make sense; it's a number of spaces.
>
> A discrete number of spaces, so int.
>
> >
> > 2. Should the range be [1,MAXINT] or [1,16] or [1,something-else]?
> > Once that is decided, I think clamp on use would be the most
> > consistent with other similar properties, but that's worth checking.
>
> If we go with "MAXINT" (which is not my preference), I think there'd
> need to be some testing of
> the various code paths and pipelines to be sure that various values from
> large, through extreme,
> all do something sensible, and of course, no exceptions or crashes.
>
> Various code paths means Text, TextFlow,  linewrapping or not ...
> complex text and simple text too.
> Perhaps complex text should be tested anyway, although I've been
> assuming that we are handling
> tab spacing outside of that but didn't verify it.
>
> -phil.
>
> >
> > -- Kevin
> >
> >
> > On 10/17/2019 12:11 PM, Scott Palmer wrote:
> >> You’re right.  Something I was reading indicated that while there was
> >> no default unit, ‘px’ was implicitly appended.  I can’t find that
> >> now. Go figure.
> >>
> >> Everything I find now about CSS tab-size is in agreement with what
> >> David wrote.  It’s a number of spaces.  With units it would be a
> >> ‘length’ but nothing supports that.
> >>
> >> So I think it makes sense to add -fx-tab-size as a CSS property, only
> >> supporting a number with no units.
> >>
> >> Scott
> >>
> >>
> >>> On Oct 17, 2019, at 2:32 PM, Phil Race  wrote:
> >>>
> >>> Really ? It defaults to pixels ? Is that just inherited as being the
> >>> default CSS unit ?
> >>> Is that FX's implementation
> >>>
> >>> Hmm. A bit of reading about web CSS says that strictly anything
> >>> without an explicit unit should be ignored.
> >>> The only exception is zero, where it doesn't matter.
> >>>
> >>> Eg see :
> >>> https://stackoverflow.com/questions/7907749/default-unit-for-font-size
> >>>
> >>> Although I am sure there are more authoratative  sources than that.
> >>>
> >>> -phil.
> >>>
> >>> On 10/17/19 11:22 AM, Scott Palmer wrote:
> >>>> So do we go ahead and implement tabSize without the CSS support?
> >>>> I’m not sure the CSS property should be added before unit issues
> >>>> are worked out, as I think the units would be expected in the CSS
> >>>> context. E.g. CSS implicitly adds ‘px’ if no unit is specified.  If
> >>>> our tabSize units are spaces, that breaks.
> >>>>
> >>>> Scott
> 

Re: Problem with gradle ...

2019-10-31 Thread Scott Palmer
The wrapper script works just like the gradle command but uses the gradle 
version specified by the project.

See https://docs.gradle.org/current/userguide/gradle_wrapper.html 



> On Oct 31, 2019, at 9:58 AM, Jeanette Winzenburg  
> wrote:
> 
> 
> Zitat von Nir Lisker :
> 
>> Did you run the wrapper with gradlew or just gradle? The latter uses the
>> "global" version installed on the OS which might not be up to date (use
>> 'gradle --version' to check).
>> 
> 
> 
> in my cygwin console I type:
> 
> gradle
> 
> and get the error message .. hmm ... so, yeah seems to be global version 
> that's out of date.
> 
> Are you saying that using gradlew (*cough - how exactly?) would keep the 
> required version up-to-date?
> 
> Thanks
> Jeanette
> 
>> - Nir
>> 
>> On Thu, Oct 31, 2019 at 3:41 PM Jeanette Winzenburg 
>> wrote:
>> 
>>> 
>>> .. fails (gradle run from cygwin console) with:
>>> 
>>> * Where:
>>> Build file
>>> 'C:\Daten\data-for-work\eclipse\gitrep-openjdk\jfx-fork\build.gradle'
>>> line: 250
>>> 
>>> * What went wrong:
>>> A problem occurred evaluating root project 'jfx-fork'.
>>> > FAIL: Gradle version too old: 4.10.2; must be at least 5.3
>>> 
>>> which is rather clear in itself, but ... how to update? It seems to
>>> too nothing, not even list the tasks
>>> 
>>> CU, Jeanette
>>> 



Build Problem on macOS with OpenJDK 13 and Gradle 6.0-rc-1

2019-10-24 Thread Scott Palmer
I’m getting this:

* What went wrong:
Execution failed for task ':swt:compileJava'.
> Could not resolve all files for configuration ':swt:compileClasspath'.
   > Could not find 
:org.eclipse.swt.cocoa.macosx.x86_64_3.105.3.v20170228-0512:.
 Searched in the following locations:
   - 
https://download.eclipse.org/eclipse/updates/4.6/R-4.6.3-201703010400/plugins/ivy.xml
 Required by:
 project :swt

Earlier on I see:

  module: project ':swt' (buildModule=NO)

so I’m not even sure why :swt:compileJava is running.. but it is.

This is with OpenJDK 13, and Gradle 6.0-rc-1.

I know the jump to Gradle 6.0 has not been officially made yet, but I also know 
it is coming for the JDK 13 support.

When I use OpenJDK 12 and gradlew the build mostly works.

Though even with OpenJDK 12 and gradlew the tests fail:

> Task :base:test

test.javafx.util.converter.LocalDateTimeStringConverterTest > 
toString_to_fromString_testRoundtrip[0] FAILED
java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' 
could not be parsed, unparsed text found at index 19
at 
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2052)
at 
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1877)
at 
javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
at 
javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
at 
test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)

5222 tests completed, 1 failed, 27 skipped


Regards,

Scott




OpenJFX.io points to old repo

2019-10-19 Thread Scott Palmer
The Let's do it! " link at
https://openjfx.io still points to
https://github.com/javafxports/openjdk-jfx instead of
https://github.com/openjdk/jfx

Scott


Re: JDK-8130738 TextFlow's tab width is static

2019-10-17 Thread Scott Palmer
I think what we’ve settled on fits CSS for the web. I agree we shouldn’t 
deviate from that if possible. 

Scott

> On Oct 17, 2019, at 5:30 PM, Pedro Duque Vieira  
> wrote:
> 
> Hi,
> 
> Kevin asked for developers opinions on this issue, just thought I'd leave
> my own.
> 
> Didn't have time to read the thread thoroughly enough, don't have much time
> at the moment to do it. Apologies for that.
> 
> Just wanted to make a comment about the CSS support for this feature. I
> think if you add it, it would be great if it follows the CSS web spec or at
> least it doesn't go against it.
> I think there's a lot of value if we start more and more following the web
> css spec, it would mean a web designer could eventually transfer his skills
> directly to javafx or that we could use tools used in the web or that we
> could simply copy paste a CSS web example into JavaFX and it would just
> work (though we're still a bit far from that but could be a possibility in
> the future).
> 
> There are a good deal of big companies already involved in developing web
> css, I'm sure they've put a lot of thought into it (not speaking of the
> early days of CSS which was very bad).
> 
> Thanks,
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com


Re: JDK-8130738 TextFlow's tab width is static

2019-10-17 Thread Scott Palmer
You’re right.  Something I was reading indicated that while there was no 
default unit, ‘px’ was implicitly appended.  I can’t find that now. Go figure.

Everything I find now about CSS tab-size is in agreement with what David wrote. 
 It’s a number of spaces.  With units it would be a ‘length’ but nothing 
supports that.

So I think it makes sense to add -fx-tab-size as a CSS property, only 
supporting a number with no units.

Scott


> On Oct 17, 2019, at 2:32 PM, Phil Race  wrote:
> 
> Really ? It defaults to pixels ? Is that just inherited as being the default 
> CSS unit ?
> Is that FX's implementation
> 
> Hmm. A bit of reading about web CSS says that strictly anything without an 
> explicit unit should be ignored.
> The only exception is zero, where it doesn't matter.
> 
> Eg see : 
> https://stackoverflow.com/questions/7907749/default-unit-for-font-size
> 
> Although I am sure there are more authoratative  sources than that.
> 
> -phil.
> 
> On 10/17/19 11:22 AM, Scott Palmer wrote:
>> So do we go ahead and implement tabSize without the CSS support?   I’m not 
>> sure the CSS property should be added before unit issues are worked out, as 
>> I think the units would be expected in the CSS context.  E.g. CSS implicitly 
>> adds ‘px’ if no unit is specified.  If our tabSize units are spaces, that 
>> breaks.
>> 
>> Scott
>> 
>>> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth  
>>> wrote:
>>> 
>>> It might make sense to just add the tabSize property now, and later 
>>> consider adding a tabUnits property in the future if needed. By default, 
>>> having the units be "number of spaces in the current font" is what makes 
>>> the most sense, so before we could add tabUnits we would need to extend it 
>>> as you suggest. I'm not sure it's needed, though, so that would be another 
>>> reason not to do it now.
>>> 
>>> It's probably best to have the type of tabSize be double rather than int. 
>>> We do this for most attributes to leave the door open for fractional 
>>> values. I don't know why anyone would want a tab that was 5.7 spaces, but 
>>> if we ever were to add a tabUnits property, I could easily see wanting 
>>> fractional values for some units.
>>> 
>>> -- Kevin
>>> 
>>> On 10/17/2019 10:40 AM, Scott Palmer wrote:
>>>> Hi Phil,
>>>> 
>>>> Thanks for taking a look.  I was going to get back to this soon to attempt 
>>>> adding the CSS property as you mention in your previous email.  I 
>>>> considered tabSize as a name as well.  I don’t have a preference if we 
>>>> leave things as representing tabs as a number of spaces.  But it wouldn’t 
>>>> be too difficult to support units, making it mostly compatible with CSS 
>>>> rules.  The way I envision that is having two properties, tabSize and 
>>>> tabUnit.
>>>> 
>>>> David mentioned javafx.css.SizeUnits… I looked quickly at the java docs 
>>>> for it, and it’s basically undocumented .  So I went to 
>>>> https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit 
>>>> like ‘ems’ but meaning the width of a space in the current font.  The 
>>>> problem with that is it would leave out the possibility to set the tab 
>>>> width to anything relative to the current implementation of 8 spaces. (In 
>>>> hindsight it should have been implemented based on ‘ems’, which for a 
>>>> fixed width font as typically used in a code editor would be the same as 8 
>>>> spaces anyway)
>>>> Do we add something to SizeUnits so we can work around this?  e.g. ‘fxsp’  
>>>> (FX-space - fx prefix to avoid a potential collision with any future 
>>>> official CSS units)
>>>> 
>>>> // Two tab-related properties
>>>> public void setTabSize(int size); // defaults to 8
>>>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space 
>>>> in current font
>>>> 
>>>> If we did the above, I would consider adding this for convenience:
>>>> public void setTabWidth(int size, TabUnits units);
>>>> 
>>>> As far as setting a range, I’m not sure there is any worthwhile benefit to 
>>>> enforcing a maximum.  If we want to store the value in a short instead of 
>>>> an int to potentially save a couple bytes, sure.  Otherwise, if someone 
>>>> wants to set tabs to be 20 spaces or 100, why should we prevent it?  If 
>>>> there isn't a performance or memo

Re: JDK-8130738 TextFlow's tab width is static

2019-10-17 Thread Scott Palmer
So do we go ahead and implement tabSize without the CSS support?   I’m not sure 
the CSS property should be added before unit issues are worked out, as I think 
the units would be expected in the CSS context.  E.g. CSS implicitly adds ‘px’ 
if no unit is specified.  If our tabSize units are spaces, that breaks.

Scott

> On Oct 17, 2019, at 2:16 PM, Kevin Rushforth  
> wrote:
> 
> It might make sense to just add the tabSize property now, and later consider 
> adding a tabUnits property in the future if needed. By default, having the 
> units be "number of spaces in the current font" is what makes the most sense, 
> so before we could add tabUnits we would need to extend it as you suggest. 
> I'm not sure it's needed, though, so that would be another reason not to do 
> it now.
> 
> It's probably best to have the type of tabSize be double rather than int. We 
> do this for most attributes to leave the door open for fractional values. I 
> don't know why anyone would want a tab that was 5.7 spaces, but if we ever 
> were to add a tabUnits property, I could easily see wanting fractional values 
> for some units.
> 
> -- Kevin
> 
> On 10/17/2019 10:40 AM, Scott Palmer wrote:
>> Hi Phil,
>> 
>> Thanks for taking a look.  I was going to get back to this soon to attempt 
>> adding the CSS property as you mention in your previous email.  I considered 
>> tabSize as a name as well.  I don’t have a preference if we leave things as 
>> representing tabs as a number of spaces.  But it wouldn’t be too difficult 
>> to support units, making it mostly compatible with CSS rules.  The way I 
>> envision that is having two properties, tabSize and tabUnit.
>> 
>> David mentioned javafx.css.SizeUnits… I looked quickly at the java docs for 
>> it, and it’s basically undocumented .  So I went to 
>> https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit 
>> like ‘ems’ but meaning the width of a space in the current font.  The 
>> problem with that is it would leave out the possibility to set the tab width 
>> to anything relative to the current implementation of 8 spaces. (In 
>> hindsight it should have been implemented based on ‘ems’, which for a fixed 
>> width font as typically used in a code editor would be the same as 8 spaces 
>> anyway)
>> Do we add something to SizeUnits so we can work around this?  e.g. ‘fxsp’  
>> (FX-space - fx prefix to avoid a potential collision with any future 
>> official CSS units)
>> 
>> // Two tab-related properties
>> public void setTabSize(int size); // defaults to 8
>> public void setTabUnits(SizeUnits units); // ?? no unit for width of space 
>> in current font
>> 
>> If we did the above, I would consider adding this for convenience:
>> public void setTabWidth(int size, TabUnits units);
>> 
>> As far as setting a range, I’m not sure there is any worthwhile benefit to 
>> enforcing a maximum.  If we want to store the value in a short instead of an 
>> int to potentially save a couple bytes, sure.  Otherwise, if someone wants 
>> to set tabs to be 20 spaces or 100, why should we prevent it?  If there 
>> isn't a performance or memory impact, I wouldn’t enforce a maximum.
>> 
>> Ignoring any out of range values rather than clamping seems fine to me as 
>> well.  I was thinking of what happens if the value was bound to another 
>> value that strayed out of range. Clamping would get you as close as possible 
>> to the bound value, rather than stuck at the previously observed value.  I 
>> just guessed that would be preferred, but if ignoring is more consistent 
>> with other values, then I agree it makes sense.  As long as the behaviour is 
>> documented, I can’t think of any significant downside either way.
>> 
>> 
>> Regards,
>> 
>> Scott
>> 
>> 
>>> On Oct 17, 2019, at 12:45 PM, Phil Race  wrote:
>>> 
>>> Hi,
>>> 
>>> Some more points which I thought about but for whatever reason did not pen 
>>> ..
>>> 
>>> First one minor thing: tabWidth is an OK name, but it does not
>>> conjure up that the value you specify isn't a width in pixels but the
>>> number of discrete space characters to use. FWIW CSS calls it tab-size.
>>> But CSS then supports pixels and ems .. that complicates matters a lot.
>>> 
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
>>> 
>>> Thee rest is mostly to do with "legal or sensible values"
>>> 
>>> You have :
>>> if (spaces < 0)
>>> spaces = 0;
>>> 
>>> 

Re: JDK-8130738 TextFlow's tab width is static

2019-10-17 Thread Scott Palmer
Hi Phil,

Thanks for taking a look.  I was going to get back to this soon to attempt 
adding the CSS property as you mention in your previous email.  I considered 
tabSize as a name as well.  I don’t have a preference if we leave things as 
representing tabs as a number of spaces.  But it wouldn’t be too difficult to 
support units, making it mostly compatible with CSS rules.  The way I envision 
that is having two properties, tabSize and tabUnit.

David mentioned javafx.css.SizeUnits… I looked quickly at the java docs for it, 
and it’s basically undocumented .  So I went to 
https://www.w3.org/TR/css-values-3/#lengths and I see there is no CSS unit like 
‘ems’ but meaning the width of a space in the current font.  The problem with 
that is it would leave out the possibility to set the tab width to anything 
relative to the current implementation of 8 spaces. (In hindsight it should 
have been implemented based on ‘ems’, which for a fixed width font as typically 
used in a code editor would be the same as 8 spaces anyway)
Do we add something to SizeUnits so we can work around this?  e.g. ‘fxsp’  
(FX-space - fx prefix to avoid a potential collision with any future official 
CSS units)

// Two tab-related properties
public void setTabSize(int size); // defaults to 8
public void setTabUnits(SizeUnits units); // ?? no unit for width of space in 
current font

If we did the above, I would consider adding this for convenience:
public void setTabWidth(int size, TabUnits units); 

As far as setting a range, I’m not sure there is any worthwhile benefit to 
enforcing a maximum.  If we want to store the value in a short instead of an 
int to potentially save a couple bytes, sure.  Otherwise, if someone wants to 
set tabs to be 20 spaces or 100, why should we prevent it?  If there isn't a 
performance or memory impact, I wouldn’t enforce a maximum.

Ignoring any out of range values rather than clamping seems fine to me as well. 
 I was thinking of what happens if the value was bound to another value that 
strayed out of range. Clamping would get you as close as possible to the bound 
value, rather than stuck at the previously observed value.  I just guessed that 
would be preferred, but if ignoring is more consistent with other values, then 
I agree it makes sense.  As long as the behaviour is documented, I can’t think 
of any significant downside either way.


Regards,

Scott


> On Oct 17, 2019, at 12:45 PM, Phil Race  wrote:
> 
> Hi,
> 
> Some more points which I thought about but for whatever reason did not pen ..
> 
> First one minor thing: tabWidth is an OK name, but it does not
> conjure up that the value you specify isn't a width in pixels but the
> number of discrete space characters to use. FWIW CSS calls it tab-size.
> But CSS then supports pixels and ems .. that complicates matters a lot.
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/tab-size
> 
> Thee rest is mostly to do with "legal or sensible values"
> 
> You have :
> if (spaces < 0)
> spaces = 0;
> 
> since negative values are not something we want to support!
> But I think instead of clamping you could "ignore", any out of range value.
> This is practiced elsewhere in FX where illegal values are ignored rather than
> throwing an exception, although it might be that clamping is quite common
> in range cases.
> 
> The follow on to that is that what is a sensible maximum value.
> Currently we have int which is more than we need. For that matter so is short.
> I think we should have a documented and enforced sensible maximum.
> Perhaps it could be "8" meaning we only support reducing tab width as I
> don't know if anyone really wants to increase it.
> CSS doesn't have a limit that I can see but if we are already only supporting
> it described as number of spaces, we can have this other limitation too.
> If you think 8 is too small, then maybe 16 ?
> Also remember we can compatibly relax it later but we can't compatibly 
> tighten it.
> 
> 
> -phil.
> 
> On 10/15/19 12:17 PM, Phil Race wrote:
>> Hi,
>> 
>> I've looked over this and I don't see any issues - meaning gotchas.
>> It just provides a way to over-ride the hard-coded 8,
>> whether using a Text node directly or a TextFlow.
>> 
>> Two observations of what one might call limitations
>> 1) This is a rendering time property, which is controlled by the program.
>> A document containing tabs saved and re-rendered somewhere else
>> won't be helped.
>> 
>> 2) This just provides API on the scene graph node types, not any of the UI 
>> controls
>> which use Text nodes. Something like a CSS property may be the way to go if
>> you wanted that.
>> Text has a nested class StyleableProperties for CSS properties with which it
>> p

Re: The thing about JAR files

2019-10-17 Thread Scott Palmer
What’s in the jar manifest?
How did you create the Java 12 runtime?


Scott

> On Oct 17, 2019, at 6:09 AM, AmnoJeeuw  wrote:
> 
> Has anyone notices that the JAR files produced, eclipse in my case, in 
> javafx 12+ applications do not run with an error that reads
> java -jar app.jar
> 
> Error Javafx runtime components are missing, and are required to run this 
> application.
> 
> It seems that it is quit common, since there are so many entries regarding 
> this problem on the net.
> 
> Well, any help would be nice.
> 
> 
> -- 
> This email has been checked for viruses by AVG.
> https://www.avg.com
> 


Re: JDK-8130738 TextFlow's tab width is static

2019-09-30 Thread Scott Palmer
Okay, current work relocated to a clone of the new official Git repo.
My initial implementation is here:
 
https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f 
<https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f>

I would submit it as a pull request but that seems premature since there hasn’t 
been any real discussion of challenges I’ve overlooked.  All I have are the 
famous last words, “It works for me.”

I saw in the archives a concern about tab width vs tab stops. For some reason I 
didn’t get the email.  Anyway, I don’t think arbitrary tab stop positions, at 
different intervals that is, are what was asked for.  That certainly would 
require a significantly different implementation.

Would love to keep some momentum going on this before I become busy with other 
things and won’t have time for it.

Scott

> On Sep 23, 2019, at 3:57 PM, Scott Palmer  wrote:
> 
> My current work is here 
> https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1
>  
> <https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1>
> 
> While writing a unit test I realized that the StubToolkit isn’t really 
> running the Prism layout code, so I’m not sure how that gets tested.  I made 
> it work with StubTextLayout for now.
> 
> Regards,
> 
> Scott
> 
> 
>> On Sep 20, 2019, at 12:57 PM, Scott Palmer > <mailto:swpal...@gmail.com>> wrote:
>> 
>> Thanks Kevin.
>> 
>> My current implementation appears to be working for TextFlow and Text, with 
>> the TextFlow overriding the tabWidth of the child Text nodes.  This seems to 
>> work out naturally from the way TextFlow overrides the TextLayout instance 
>> used by the Text node.
>> 
>> If there are tricky corner-cases that I’m missing, I guess figuring out all 
>> the cases it will need to handle is part of this discussion.  It didn’t seem 
>> to be that challenging so far, so perhaps I am missing something (hopefully 
>> not).  I wrote a small test app to visually see that things were working as 
>> I expected.  I have not yet written the unit tests.
>> 
>> Cheers,
>> 
>> Scott
>> 
>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >> <mailto:kevin.rushfo...@oracle.com>> wrote:
>>> 
>>> Hi Scott,
>>> 
>>> I'm sure Phil will have more comments on this. While the API seems simple 
>>> enough on the surface, I suspect that this will be a challenging feature to 
>>> implement correctly for all of the cases it will need to handle. It would 
>>> need careful review and testing as well. My only comment on the API itself 
>>> is that if we do accept this feature, it should probably go on both Text 
>>> and TextFlow, and be one of the attributes of Text that is ignored / 
>>> overridden when a Text node is in a TextFlow.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 9/18/2019 6:14 PM, Scott Palmer wrote:
>>>> I would like to implement this feature, being able to adjust the tab size 
>>>> in a TextFlow or Text node (JDK-8130738 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8130738 
>>>> <https://bugs.openjdk.java.net/browse/JDK-8130738>>).  It involves new 
>>>> public API, so I want to start a discussion about it here.  (My motivation 
>>>> is that RichTextFX suggests an entirely unacceptable workaround of 
>>>> substituting actual spaces when the tab character is typed and cites the 
>>>> lack of this API.)
>>>> 
>>>> I’ve already jumped the gun and taken a crack at an implementation.  It is 
>>>> currently incomplete as I was just poking around to see if it was going to 
>>>> be easy enough to not take up too much of my time.  It boils down to:
>>>> TextFlow and Text get a new property for tab width, an integer 
>>>> representing the number of spaces taken by a tab. (The value is only used 
>>>> to initialize the tab width for the TextLayout when needed.)
>>>> TextLayout interface gets a new method:  boolean setTabWidth(int spaces)
>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8;
>>>> PrismTextLayout implements the new setTabWidth API.
>>>> 
>>>> I’m not sure that the Text node needs this new property.  I figured it 
>>>> would be rarely used on that class, so I had implemented it via an added 
>>>> property in the private TextAttributes class.  Maybe it isn’t needed at 
>>>> all.
>>>> 
>>>> What’s the next step?
>>>> 
>>>> Regards,
>>>> 
>>>> Scott
>>> 
>> 
> 



Re: JDK-8130738 TextFlow's tab width is static

2019-09-23 Thread Scott Palmer
My current work is here 
https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1
 
<https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1>

While writing a unit test I realized that the StubToolkit isn’t really running 
the Prism layout code, so I’m not sure how that gets tested.  I made it work 
with StubTextLayout for now.

Regards,

Scott


> On Sep 20, 2019, at 12:57 PM, Scott Palmer  wrote:
> 
> Thanks Kevin.
> 
> My current implementation appears to be working for TextFlow and Text, with 
> the TextFlow overriding the tabWidth of the child Text nodes.  This seems to 
> work out naturally from the way TextFlow overrides the TextLayout instance 
> used by the Text node.
> 
> If there are tricky corner-cases that I’m missing, I guess figuring out all 
> the cases it will need to handle is part of this discussion.  It didn’t seem 
> to be that challenging so far, so perhaps I am missing something (hopefully 
> not).  I wrote a small test app to visually see that things were working as I 
> expected.  I have not yet written the unit tests.
> 
> Cheers,
> 
> Scott
> 
>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth  
>> wrote:
>> 
>> Hi Scott,
>> 
>> I'm sure Phil will have more comments on this. While the API seems simple 
>> enough on the surface, I suspect that this will be a challenging feature to 
>> implement correctly for all of the cases it will need to handle. It would 
>> need careful review and testing as well. My only comment on the API itself 
>> is that if we do accept this feature, it should probably go on both Text and 
>> TextFlow, and be one of the attributes of Text that is ignored / overridden 
>> when a Text node is in a TextFlow.
>> 
>> -- Kevin
>> 
>> 
>> On 9/18/2019 6:14 PM, Scott Palmer wrote:
>>> I would like to implement this feature, being able to adjust the tab size 
>>> in a TextFlow or Text node (JDK-8130738 
>>> <https://bugs.openjdk.java.net/browse/JDK-8130738>).  It involves new 
>>> public API, so I want to start a discussion about it here.  (My motivation 
>>> is that RichTextFX suggests an entirely unacceptable workaround of 
>>> substituting actual spaces when the tab character is typed and cites the 
>>> lack of this API.)
>>> 
>>> I’ve already jumped the gun and taken a crack at an implementation.  It is 
>>> currently incomplete as I was just poking around to see if it was going to 
>>> be easy enough to not take up too much of my time.  It boils down to:
>>> TextFlow and Text get a new property for tab width, an integer representing 
>>> the number of spaces taken by a tab. (The value is only used to initialize 
>>> the tab width for the TextLayout when needed.)
>>> TextLayout interface gets a new method:  boolean setTabWidth(int spaces)
>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8;
>>> PrismTextLayout implements the new setTabWidth API.
>>> 
>>> I’m not sure that the Text node needs this new property.  I figured it 
>>> would be rarely used on that class, so I had implemented it via an added 
>>> property in the private TextAttributes class.  Maybe it isn’t needed at all.
>>> 
>>> What’s the next step?
>>> 
>>> Regards,
>>> 
>>> Scott
>> 
> 



Use of Hashtable in Prism

2019-09-23 Thread Scott Palmer
I just noticed that NetBeans is warning me about use of an “obsolete 
collection” in PrismTextLayout.java.

Is there a reason this isn’t using HashMap or ConcurrentHashMap ?

Scott



Re: JDK-8130738 TextFlow's tab width is static

2019-09-20 Thread Scott Palmer
Thanks Kevin.

My current implementation appears to be working for TextFlow and Text, with the 
TextFlow overriding the tabWidth of the child Text nodes.  This seems to work 
out naturally from the way TextFlow overrides the TextLayout instance used by 
the Text node.

If there are tricky corner-cases that I’m missing, I guess figuring out all the 
cases it will need to handle is part of this discussion.  It didn’t seem to be 
that challenging so far, so perhaps I am missing something (hopefully not).  I 
wrote a small test app to visually see that things were working as I expected.  
I have not yet written the unit tests.

Cheers,

Scott

> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth  
> wrote:
> 
> Hi Scott,
> 
> I'm sure Phil will have more comments on this. While the API seems simple 
> enough on the surface, I suspect that this will be a challenging feature to 
> implement correctly for all of the cases it will need to handle. It would 
> need careful review and testing as well. My only comment on the API itself is 
> that if we do accept this feature, it should probably go on both Text and 
> TextFlow, and be one of the attributes of Text that is ignored / overridden 
> when a Text node is in a TextFlow.
> 
> -- Kevin
> 
> 
> On 9/18/2019 6:14 PM, Scott Palmer wrote:
>> I would like to implement this feature, being able to adjust the tab size in 
>> a TextFlow or Text node (JDK-8130738 
>> <https://bugs.openjdk.java.net/browse/JDK-8130738>).  It involves new public 
>> API, so I want to start a discussion about it here.  (My motivation is that 
>> RichTextFX suggests an entirely unacceptable workaround of substituting 
>> actual spaces when the tab character is typed and cites the lack of this 
>> API.)
>> 
>> I’ve already jumped the gun and taken a crack at an implementation.  It is 
>> currently incomplete as I was just poking around to see if it was going to 
>> be easy enough to not take up too much of my time.  It boils down to:
>> TextFlow and Text get a new property for tab width, an integer representing 
>> the number of spaces taken by a tab. (The value is only used to initialize 
>> the tab width for the TextLayout when needed.)
>> TextLayout interface gets a new method:  boolean setTabWidth(int spaces)
>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8;
>> PrismTextLayout implements the new setTabWidth API.
>> 
>> I’m not sure that the Text node needs this new property.  I figured it would 
>> be rarely used on that class, so I had implemented it via an added property 
>> in the private TextAttributes class.  Maybe it isn’t needed at all.
>> 
>> What’s the next step?
>> 
>> Regards,
>> 
>> Scott
> 



JDK-8130738 TextFlow's tab width is static

2019-09-18 Thread Scott Palmer
I would like to implement this feature, being able to adjust the tab size in a 
TextFlow or Text node (JDK-8130738 
).  It involves new public 
API, so I want to start a discussion about it here.  (My motivation is that 
RichTextFX suggests an entirely unacceptable workaround of substituting actual 
spaces when the tab character is typed and cites the lack of this API.)

I’ve already jumped the gun and taken a crack at an implementation.  It is 
currently incomplete as I was just poking around to see if it was going to be 
easy enough to not take up too much of my time.  It boils down to:
TextFlow and Text get a new property for tab width, an integer representing the 
number of spaces taken by a tab. (The value is only used to initialize the tab 
width for the TextLayout when needed.)
TextLayout interface gets a new method:  boolean setTabWidth(int spaces)
TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8;
PrismTextLayout implements the new setTabWidth API.

I’m not sure that the Text node needs this new property.  I figured it would be 
rarely used on that class, so I had implemented it via an added property in the 
private TextAttributes class.  Maybe it isn’t needed at all.

What’s the next step?

Regards,

Scott

Heads up - Building with Gradle 5.6.2 leaves .property files out of jars

2019-09-18 Thread Scott Palmer
I know that the supported Gradle version is 5.3, but I decided to try with
the version of Gradle I had installed (5.6.2) and things appeared to be
working.  Until I got a message about QuantumMessagesBundle not found when
I tried to run my test app.  Eventually I narrowed it down to the build
with Gradle 5.6.2 not having the .properties files in the
javafx.graphics.jar.

I would normally shut up and use ./gradlew like I'm supposed to, but with
the recent release of Java 13, and the fact that Gradle 5.3 (and 5.6.2)
can't handle the class file version from Java 13, I figured a Gradle
upgrade is going to be necessary soon.


Cheers,

Scott


LocalDateTimeStringConverterTest failing

2019-09-16 Thread Scott Palmer
I was looking into working on an issue but before I got very far I ran into
this test failing.  I'm building on macOS.

I've tried with OpenJDK 11.0.2 and OpenJDK 12.0.2.

gradle :base:test

results in:

> Task :base:test

test.javafx.util.converter.LocalDateTimeStringConverterTest >
toString_to_fromString_testRoundtrip[0] FAILED
java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.'
could not be parsed, unparsed text found at index 19
at
java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2049)
at
java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1874)
at
javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208)
at
javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159)
at
test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131)

5209 tests completed, 1 failed, 27 skipped

What am I missing?

Regards,

Scott


Anyone testing on macOS 10.15 betas?

2019-09-12 Thread Scott Palmer
My JavaFX app using JavaFX 13 on OpenJDK 12.0.2 crashes every time I close my 
main window.  I’m not 100% sure if it is a JavaFX issue, but just in case 
here’s a stack trace. I see libglass.dylib, though it is a few frames away from 
the crash point.:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib  0x7fff6a488726 __psynch_cvwait + 10
1   libsystem_pthread.dylib 0x7fff6a549082 _pthread_cond_wait + 
701
2   libjvm.dylib0x00010ffe32d2 
os::PlatformEvent::park() + 126
3   libjvm.dylib0x00010ffb95c2 
Monitor::ILock(Thread*) + 152
4   libjvm.dylib0x00010ffb9a59 
Monitor::lock_without_safepoint_check() + 33
5   libjvm.dylib0x000110049e5a 
SafepointSynchronize::block(JavaThread*) + 324
6   libjvm.dylib0x0001100e45f0 
JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) + 162
7   libjvm.dylib0x00010fdd9d12 jni_NewStringUTF + 
142
8   libglass.dylib  0x0001370c6cf9 +[GlassHelper 
ClassForName:withEnv:] + 185
9   libglass.dylib  0x0001370b3d71 
-[GlassTouches(hidden) sendJavaTouchEvent:] + 1441
10  libglass.dylib  0x0001370b3721 listenTouchEvents + 
97
11  com.apple.SkyLight  0x7fff6111fdc0 
processEventTapData(void*, unsigned int, unsigned int, unsigned int, unsigned 
char*, unsigned int) + 631
12  com.apple.SkyLight  0x7fff61282680 _XPostEventTapData + 
277
13  com.apple.SkyLight  0x7fff6111faeb 
eventTapMessageHandler(__CFMachPort*, void*, long, void*) + 147
14  com.apple.CoreFoundation0x7fff32d9cfd3 __CFMachPortPerform 
+ 250
15  com.apple.CoreFoundation0x7fff32d9cecf 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41
16  com.apple.CoreFoundation0x7fff32d9ce1f __CFRunLoopDoSource1 
+ 541
17  com.apple.CoreFoundation0x7fff32d84d7c __CFRunLoopRun + 2612
18  com.apple.CoreFoundation0x7fff32d840c3 CFRunLoopRunSpecific 
+ 499
19  com.apple.HIToolbox 0x7fff31911f2d 
RunCurrentEventLoopInMode + 292
20  com.apple.HIToolbox 0x7fff31911c6d 
ReceiveNextEventCommon + 600
21  com.apple.HIToolbox 0x7fff319119f7 
_BlockUntilNextEventMatchingListInModeWithFilter + 64
22  com.apple.AppKit0x7fff2ffbbee4 _DPSNextEvent + 990
23  com.apple.AppKit0x7fff2ffbac50 
-[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] 
+ 1352
24  com.apple.AppKit0x7fff2ffb5395 -[NSApplication run] 
+ 658
25  libglass.dylib  0x0001370a7e0c -[GlassApplication 
runLoop:] + 1932
26  com.apple.Foundation0x7fff3553f89a 
__NSThreadPerformPerform + 254
27  com.apple.CoreFoundation0x7fff32da1cd1 
__CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17
28  com.apple.CoreFoundation0x7fff32da1c70 __CFRunLoopDoSource0 
+ 103
29  com.apple.CoreFoundation0x7fff32d85234 
__CFRunLoopDoSources0 + 209
30  com.apple.CoreFoundation0x7fff32d84840 __CFRunLoopRun + 1272
31  com.apple.CoreFoundation0x7fff32d840c3 CFRunLoopRunSpecific 
+ 499
32  libjli.dylib0x00010e833444 
CreateExecutionEnvironment + 400
33  libjli.dylib0x00010e82f5b7 JLI_Launch + 1311
34  java0x00010e824ca1 main + 375
35  libdyld.dylib   0x7fff6a33c2a5 start + 1


Regards,

Scott




RFR: 8185937 - Spinner with Double/Integer value factory ignores up/down arrow keys

2019-07-05 Thread Scott Palmer
Please review the fix for   JDK-8185937 - Spinner with Double/Integer value 
factory ignores up/down arrow keys

https://bugs.openjdk.java.net/browse/JDK-8185937 

 
https://github.com/javafxports/openjdk-jfx/pull/517 




Fix for JDK-8185937 Up/Down keys don't work as expected for an editable Spinner

2019-07-04 Thread Scott Palmer
I’ve added my potential fix as a comment to the issue at
https://bugs.openjdk.java.net/browse/JDK-8185937 


Scott




Re: GStreamer

2019-05-19 Thread Scott Palmer
It’s been 11 years… https://bugs.openjdk.java.net/browse/JDK-8091063 


The gstreamer integration should have been a pluggable module into the media 
framework from the beginning.  I would love to see that corrected.  Refactoring 
towards a more usable media framework that has the necessary hooks to make it 
more than a very basic player with limited codec support gets a big plus one 
from me.  I only wish I had the time to help more with actual code.  

Regards,

Scott


> On May 14, 2019, at 8:27 PM, Curtis Ruck  wrote:
> 
> Gstreamer-javafx examples:
> https://github.com/gstreamer-java/gst1-javafx-examples 
> 
> 
> I admire how javafx is wrapping gstreamer compared to the above example.
> I'd like to expand the support for more Media types and some method to
> access alternative stream data like closed captioning.  I don't want to
> reinvent the wheel, I just prefer javafx as a modern, portable framework
> over alternatives.  Java has always had poor compatibility with media
> frameworks in the past,
> 
> I look at the ideal way for me to accomplish my goals above as easily as
> possible (if I we're King for a little bit) would be to create a bolt-on
> javafx-media-extras library that pulled in additional gstreamer plugins.  I
> definitely don't want to break downstream interfaces or expose additional
> non-public APIs, I just want graceful API expansion that allows javafx to
> compete against just about every other UI toolkit.
> 
> On Tue, May 14, 2019, 20:14 Kevin Rushforth  >
> wrote:
> 
>> When you say "gstreamer-javafx" I don't know quite what you mean. The
>> gstreamer-lite library is an internal component of JavaFX and it not
>> something meant to be used by itself. Refactoring the native code in the
>> javafx.media module just so it could be used independently from JavaFX
>> doesn't seem like something that would benefit JavaFX or make it easier to
>> maintain. Rather it could create defacto interfaces that could easily break
>> when we upgrade gstreamer (which we do from time to time to keep up with
>> bug fixes, etc). It's the same reason we don't support accessing Prism or
>> Glass directly.
>> 
>> -- Kevin
>> 
>> 
>> On 5/14/2019 5:04 PM, Curtis Ruck wrote:
>> 
>> Why is splitting gstreamer-lite out not on the table, curiosity?
>> 
>> It feels a little silly to end up with two gstreamer libraries getting
>> used by a single application.  The gstreamer-javafx examples are horrible
>> compared to the existing javafx-media API.
>> 
>> 
>> 
>> On Tue, May 14, 2019, 19:55 Kevin Rushforth 
>> wrote:
>> 
>>> We don't currently plan to add support for pluggable codecs, but that
>>> might be something that the community could do, although it would be a
>>> large effort. As for splitting gstreamer-lite out of javafx.media, we
>>> are not likely to consider that.
>>> 
>>> -- Kevin
>>> 
>>> 
>>> On 5/13/2019 11:30 AM, Curtis Ruck wrote:
 I'm investigating a new application that would need tighter integration
 with gstreamer.  Is there a way to add additional gstreamer plugins and
 media types without having to maintain a fork of javafx-media?
 
 Ideally, if i did end up needing a fork, i was thinking it would make
>>> sense
 to split gstreamer-lite out of javafx-media into it's own project so I
 could easily swap in a full gstreamer dependency with 3rd project for
>>> the
 additional media types.
 
 Background: ideally looking to pull in udpsource and some additional
 pipeline plugins (GPU decoding and some subtitle related plugins).
 
 Thoughts?
 
 --
 Curtis Ruck



JMODs and Arm support

2019-04-30 Thread Scott Palmer
I noticed that there is a download on openjfx.io  for an 
11.0.2 Arm SDK, but no JMOD download for Arm.  Nor is there any 64-bit Arm 
download, making it a bit of an outlier since there are no 32-bit binaries for 
the other platforms. (The website should probably label this better.)  Is there 
any particular reason that JMOD downloads are not provided for Arm?  My build 
process is using JMODs to jlink a runtime and I now have a need to get this 
working on embedded systems, including aarch64.   I noticed that Bellsoft does 
supply an armv7/8 SDK with JavaFX modules included, but only for 32-bit, the 
64-bit version doesn’t include JavaFX.

The current practice of bundling the native libraries in the JAR files and 
extracting them at runtime seems to me to be a rather ugly hack - precisely the 
thing that JMOD addresses*.  I also expect the process of extracting a native 
library at runtime could lead to problems with anti-malware tools.   Is not the 
preferred mechanism to use link on a JMOD to produce a runtime with the native 
code in the proper place to begin with?
The Gradle scripts provided at openjfx.io  don’t support 
this model either.

I still can’t find any JMOD artifacts published to Maven Central.  I asked 
about this before and there seemed to agreement that publishing the JMOD files 
as artifacts was a reasonable thing to do.  I’m currently uploading them to our 
local Artifactory server to work around this.

*There is still an issue with the poor support for JMOD during development. You 
have to create a JRE outside of the JDK and wedge it in to your development 
process in order to debug, because JMOD isn’t supported at runtime.  I’m not 
sure if there are any plans to improve that situation.  For now I have ugly 
build scripts to use the .jar files for debugging and the JMODs for compiling 
and jlink.


On another note: Does the Arm version of OpenJFX support a desktop environment 
yet? Instead of forcing a fullscreen situation?  I would like things such as 
Dialogs and FileChoosers to work on a Raspberry Pi setup.

Regards,

Scott



Re: JDK-8193445 Performance Test (CSS applied redundantly)

2019-01-17 Thread Scott Palmer


> On Jan 17, 2019, at 3:23 PM, Tom Schindl  wrote:
> 
> Sorry to hi-jack but:
> 
>> Performance improvements and a JNI mechanism to get at native window handles 
>> are the first two items on my wish list.  Though extendable media support 
>> could potentially beat out the window handle thing.. I only need a native 
>> window handle so I can do native rendering of video frames from a non-JavaFX 
>> source.
> 
> Couldn't you leverage our DriftFX work for this?

Yes, possibly!  Thanks for reminding me. I did make note of it last month but 
it fell off the radar over the holidays. 

Scott



Re: JDK-8193445 Performance Test (CSS applied redundantly)

2019-01-17 Thread Scott Palmer
JDK-8183100 is a fixed issue.  But it basically undid the fix for 
https://bugs.openjdk.java.net/browse/JDK-8151756 

I think you mean to ask when JDK-8193445 might be addressed.

I too would like to see the performance return, and actually I’m hoping it can 
be made better than it was before. 

Performance improvements and a JNI mechanism to get at native window handles 
are the first two items on my wish list.  Though extendable media support could 
potentially beat out the window handle thing.. I only need a native window 
handle so I can do native rendering of video frames from a non-JavaFX source.

Scott 

> On Jan 17, 2019, at 8:05 AM,  
>  wrote:
> 
> Does anybody has any information about a target release for fixing
> https://bugs.openjdk.java.net/browse/JDK-8183100 , this issue causing severe
> performance degradation since JDK1.8.172?
> 
> 
> 
> Since JDK1.8.182, CSS is applied redundantly, leading too significant
> performance degradation, on scenes with many levels of hierarchy.
> 
> 
> 
> I logged this issue in two JIRA in December 2018 (more than 1 year ago) : 
> 
> https://bugs.openjdk.java.net/browse/JDK-8193445
> 
> https://bugs.openjdk.java.net/browse/JDK-8209830
> 
> 
> 
> I've reported another issue https://bugs.openjdk.java.net/browse/JDK-8199216
> , showing performance and memory issue caused by Javafx PseudoClassState
> objects. This issue could be related to the previous ones.
> 
> 
> 
> This is a really BLOCKING issue, our product is stuck with JDK1.8.162,
> blocking us for trying a migration to JDK10 or JDK11!
> 
> 
> 
> Daniel Weil (ARGOSIM)
> 



Re: OpenJFX JMOD Files

2018-12-10 Thread Scott Palmer
Inline


> On Dec 10, 2018, at 2:16 PM, August Nagro  wrote:
> 
> I wouldn't recommend publishing JMOD files on maven central since the file 
> format is not yet stable (based on zip currently, but ideally will change to 
> better compression in the future). JMOD seems to be 'unfinished business' 
> from JPMS.

I don’t see that as a problem as new versions can be uploaded as required. 

> 
> I've also found that for some reason building modular FX applications with 
> jlink + JMOD files produces significantly bigger runtime images than with the 
> SDK.

Well I don’t know what the full difference is, but for one the jmod-based 
runtime would have the native libraries in compressed. The class data may also 
be uncompressed depending on the jlink options used.

It’s too bad this is such a mess. JMOD files can’t be used at runtime, but they 
have a mechanism to hold native libraries. JAR files lack that mechanism so 
they can’t be used to make a proper runtime image.  I don’t know why a 
convention for including native libraries (in the META-INFO folder for example) 
wasn’t established, but I suspect it had to do with all the improvements they 
wanted for JMOD that didn’t happen anyway. 

JMOD now is just a mangled jar that isn’t particularly useful.  How do you 
debug code that has native libraries without the expense of creating a runtime?

Regards, 

Scott
> 
>> On Mon, Dec 10, 2018 at 11:59 AM Matthias Bläsing 
>>  wrote:
>> Hi Johan,
>> 
>> I was in a similar situation for JNA (Java Native Access) and found,
>> that sonatype accepts other package types than jar/javadoc/sources.
>> 
>> To support opening JNI libraries, the native parts need to be packed
>> differently. This packaging is an "aar" (Android Archive). I did not
>> ask sonatype, but just modified the upload, to include the aar together
>> with the primary jar, javadocs and source.
>> 
>> You can see for the jna library itself:
>> 
>> https://repo1.maven.org/maven2/net/java/dev/jna/jna/5.1.0/
>> 
>> JNA uses the maven deploy plugin with the deploy-file goal and uploads
>> the files together (from the ant build script):
>> 
>> 
>>   > value="org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy-file"/>
>>   
>>   
>>   
>>   
>>   > value="-Dfiles=${maven-sources-jar},${maven-javadoc-jar},${dist-aar}"/>
>>   
>>   
>> 
>> 
>> Maybe that helps
>> 
>> Matthias
>> 
>> Am Sonntag, den 09.12.2018, 20:36 +0100 schrieb Johan Vos:
>> > I got the use case. I think it should be possible, although in general
>> > uploading to the OSS sonatype repository requires uploading jars for the
>> > classes, sources and javadoc. There is no procedure yet (afaik) for
>> > uploading mods, but we can see if that works.
>> > 
>> > - Johan
>> > 
>> > On Fri, Dec 7, 2018 at 11:20 PM Scott Palmer  wrote:
>> > 
>> > > Is there a reason not to make the jmod files available as artifacts on
>> > > Maven Central?
>> 


OpenJFX JMOD Files

2018-12-07 Thread Scott Palmer
Is there a reason not to make the jmod files available as artifacts on
Maven Central?

The idea being that I can then use dependency management in my Gradle
script and not require the extra setup and configuration of a JavaFX SDK -
yet still be able to use the jmod files as input to jlink.  I would rather
create a runtime with the native libraries in place than use the modular
jars and have the penalty of extracting native libraries at runtime.

It seems I may need to use both the modular jars and the jmods because
apparently jmods can't be used at runtime.  That makes debugging awkward.


Regards,

Scott


Re: JavaFX Media module crashes jdeps

2018-12-03 Thread Scott Palmer
Thanks, that does seem to be the issue.

Is this the sort of thing that might be back-ported to a 11.0.2 release?
I'm trying to automate as much of my build as possible and special casing
stuff to work around issues like this makes things a bit messy.  It's just
one of several little things that is making moving beyond JDK 8 a rather
tedious affair.  Almost there though...

Cheers,
Scott


On Mon, Dec 3, 2018 at 12:45 PM Kevin Rushforth 
wrote:

> I should add that fixing the following bug in JavaFX should avoid the
> problem:
>
> https://bugs.openjdk.java.net/browse/JDK-8211900
>
> It's on my list to fix for openjfx12.
>
> -- Kevin
>
>
> On 12/3/2018 9:27 AM, Kevin Rushforth wrote:
> > I guess you are running into:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8211887
> >
> > -- Kevin
> >
> > On 12/3/2018 9:21 AM, Scott Palmer wrote:
> >> I use a Gradle script to run jdeps to get a module list for jlink.
> >>
> >> This command line (excuse the long paths into the Gradle cache):
> >>
> >> jdeps --print-module-deps --module-path
> >>
> C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar
>
> >> C:\path\to\my\Application.jar
> >>
> >> Causes this exception:
> >> Exception in thread "main" java.lang.NullPointerException
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124)
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110)
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65)
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124)
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97)
> >>  at
> >>
> jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023)
> >>  at
> >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560)
> >>  at
> >> jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519)
> >>  at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49)
> >>
> >> Without the JavaFX modules listed the output works fine.
> >>
> >> So I started to narrow it down and found that
> >> javafx-media-11.0.1-win.jar seems to cause the exception
> >>
> >> If I make a Java runtime that includes the same JavaFX modules (with
> >> media) and use --system instead of --module-path it also works fine.
> >>
> >> Got any ideas what might be going on?
> >>
> >> Thanks,
> >>
> >> Scott
> >>
> >
> >
>
>
>


JavaFX Media module crashes jdeps

2018-12-03 Thread Scott Palmer
I use a Gradle script to run jdeps to get a module list for jlink.

This command line (excuse the long paths into the Gradle cache):

jdeps --print-module-deps --module-path 
C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-fxml\11.0.1\2ef70dd2fee84fa4f18c9cbdcabe91e93e8b08ea\javafx-fxml-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-web\11.0.1\4912c3f5184d1bea0f8d25af976aab1a521081ac\javafx-web-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\c4a7cbfbb28713a29883f7c1c3433b841239f8e7\javafx-controls-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-controls\11.0.1\61cf91bf3494d0616216f49c9e1d183d170adf0a\javafx-controls-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-swing\11.0.1\c02350b12b940cb6ed14f1755e056c6e557f8b48\javafx-swing-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\d261eabc16e8037e403785dcd822b9d42079dc42\javafx-media-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-media\11.0.1\fd095047b7d06f6c7b16afe8cf9dffccab5d4494\javafx-media-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\8ec761df8ab0df38ea43f4e7a3018a2991f786f6\javafx-graphics-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-graphics\11.0.1\e062cb01783effc6413abbd94d1838f6b0add209\javafx-graphics-11.0.1.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\24f4f0f3a4c3e1ea536e463781fe799e3a7ac857\javafx-base-11.0.1-win.jar;C:\Users\spalmer\.gradle\caches\modules-2\files-2.1\org.openjfx\javafx-base\11.0.1\f1354a284f4151d20358e776f6ff68ee35bbb96d\javafx-base-11.0.1.jar
 C:\path\to\my\Application.jar

Causes this exception:
Exception in thread "main" java.lang.NullPointerException
at 
jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.requiresTransitive(ModuleGraphBuilder.java:124)
at 
jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.buildGraph(ModuleGraphBuilder.java:110)
at 
jdk.jdeps/com.sun.tools.jdeps.ModuleGraphBuilder.reduced(ModuleGraphBuilder.java:65)
at 
jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.modules(ModuleExportsAnalyzer.java:124)
at 
jdk.jdeps/com.sun.tools.jdeps.ModuleExportsAnalyzer.run(ModuleExportsAnalyzer.java:97)
at 
jdk.jdeps/com.sun.tools.jdeps.JdepsTask$ListModuleDeps.run(JdepsTask.java:1023)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:560)
at jdk.jdeps/com.sun.tools.jdeps.JdepsTask.run(JdepsTask.java:519)
at jdk.jdeps/com.sun.tools.jdeps.Main.main(Main.java:49)

Without the JavaFX modules listed the output works fine.

So I started to narrow it down and found that javafx-media-11.0.1-win.jar seems 
to cause the exception

If I make a Java runtime that includes the same JavaFX modules (with media) and 
use --system instead of --module-path it also works fine.

Got any ideas what might be going on?

Thanks,

Scott



Re: JDK-8193445 Performance Test

2018-11-07 Thread Scott Palmer



> On Nov 7, 2018, at 8:37 AM, David Grieve  wrote:
> 
> ...
> 
> Reapplying CSS to a Node but not its children could cause a problem if there 
> are styles in the parent or the parent's parents that affect the children. It 
> seems like bypassing children in reapplyCSS is bound to cause a regression.

I agree that it is necessary to re-apply CSS to child nodes when the parent 
node CSS changes.  The issue that I originally reported was that I could see 
that child nodes had CSS re-applied more than once. The number of times CSS is 
applied is currently proportional to how deep in the scene graph hierarchy the 
node is.

When a subtree is added to the scene graph, I would expect that CSS can be 
reapplied to each node only once, so long as it is done in a top-down manner.

I could be wrong, I’m not certain how rules relating to sibling nodes might 
invalidate that assumption. In HTML there is the concept of adjacent sibling 
combinator, e.g. “img + p" for paragraphs that come immediately after any 
image.  I don’t think JavaFX has anything like that thoughts o top-down should 
work out.

Scott





Re: Filling the Packager gap

2018-09-26 Thread Scott Palmer
Does jlink work for non-modular stuff?  The last time I tried it complained to 
me too.  I guess it gives up because it can’t automatically figure out module 
dependencies.  The error below shows jlink is what is complaining.

Scott


> On Sep 26, 2018, at 3:44 PM, Kevin Rushforth  
> wrote:
> 
> jpackager should work for non-modular applications as well as modular ones. 
> We've tested it for simple applications with or without FX. In the latter 
> case, the testing I've done has been done by first using jlink to create a 
> Java runtime with the needed JDK modules + the openjfx11 modules (using the 
> jomds).
> 
> Andy might have additional comments.
> 
> -- Kevin
> 
> 
> On 9/26/2018 11:50 AM, Sverre Moe wrote:
>> I have tried this jpackager a bit. It is working fine packaging a Java
>> modular project.
>> However it fails to package a none modular project. I modified my project
>> and removed the modularization and tried again to see if it would work to
>> package our legacy Java 8 project (though now built with JDK 11 and with
>> dependencies on openjfx 11).
>> 
>> I was under the impression that the jpackager should also work to package
>> non-modular projects.
>> 
>> The Gradle distribution task produces an tar archive with all the
>> dependencies and my own JAR, which I am using as input to the jpackager.
>> 
>> This produces the RPM for the modular project:
>> sverre@mintaka:~/workspace/movies/build/distributions/movies-1.0-SNAPSHOT/lib>
>> ~/Downloads/jdk.packager-linux/jpackager create-installer --output outputDir
>> --verbose --echo-mode --module-path . --module
>> no.smeaworks.movies/no.smeaworks.movies.MoviesApplication
>> 
>> Using the jpackager to package non modular project:
>> sverre@mintaka:~/workspace/movies-java11/build/distributions/movies-1.0-SNAPSHOT>
>> ~/Downloads/jdk.packager-linux/jpackager create-installer --input lib 
>> --output
>> outputDir --verbose --echo-mode --class
>> no.smeaworks.movies.MoviesApplication --main-jar movies-1.0-SNAPSHOT.jar
>> 
>> 
>> ECHO-MODE: Running [rpmbuild, --version]
>> 
>> "Adding modules: [] to runtime image."
>> 
>> ECHO-MODE: Running jlink [
>> --output =
>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
>> --module-path = [/usr/lib64/jvm/java-11-openjdk-11/jmods]
>> --add-modules = []
>> --limit-modules = []
>> --exclude-files = .*\.diz
>> --strip-native-commands = false
>> ]
>> /tmp/jdk.packager8937818818558013564/images/linux-rpm.image/movies/runtime
>> Exception: jdk.tools.jlink.plugin.PluginException: java.io.IOException:
>> jdk.tools.jlink.plugin.PluginException: ModuleTarget attribute is missing
>> for java.base module
>> Config files are saved to /tmp/jdk.packager8937818818558013564/linux. Use
>> them to customize package.
>> Exception in thread "main" jdk.packager.internal.PackagerException: Error:
>> Bundler "RPM Bundle" (rpm) failed to produce a bundle.
>>at
>> jdk.packager/jdk.packager.internal.Arguments.generateBundle(Arguments.java:642)
>> 
>>at
>> jdk.packager/jdk.packager.internal.Arguments.processArguments(Arguments.java:582)
>> 
>>at jdk.packager/jdk.packager.Main.run(Main.java:71)
>>at jdk.packager/jdk.packager.Main.main(Main.java:47)
>> 
>> 
>> Is my presumption wrong that it should package also non modular projects,
>> or am I missing some runtime flags to jpackager?
>> 
>> Johan, you mentioned that Gluon is using this to package SceneBuilder 11. I
>> reckon that Gluon has yet to modularize SceneBuilder? Can you provide some
>> insight how you use jpackage to build the project? I could not find
>> anything on it in the Gluon SceneBuilder GitHub repository.
>> 
>> /Sverre
>> 
>> Den ons. 19. sep. 2018 kl. 10:56 skrev Johan Vos :
>> 
>>> Hi,
>>> 
>>> As promised, we looked into an interim solution for the packager-gap. Work
>>> for the new Java Packager (12?) is being done in the OpenJDK sandbox repo.
>>> We backported the required changes to an OpenJDK 11 mirror:
>>> https://github.com/johanvos/openjdk-mobile11/tree/packager
>>> 
>>> With this, we created modified OpenJDK 11 builds that contain the packager
>>> (wrapper/exe + module including native library). They can be downloaded and
>>> tested/used at
>>> 
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.zip
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-osx.zip
>>> http://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip
>>> 
>>> For Windows, you have to unzip the bundle in the same directory as the JDK,
>>> as the packager wrapper expect to find the java binary at the same level.
>>> 
>>> Note that these are not products. We use them internally to create
>>> installers (e.g. we're using them for Scene Builder 11 and that works
>>> fine), and they do what we expect them to do, but there are no guarantees
>>> of course so at least for now I recommend using them in development only
>>> (or even better, look at the changes and contribute to
>>> 

Re: NativeLibLoader - installLibraryFromResource - RuntimeImage

2018-07-27 Thread Scott Palmer


> On Jul 27, 2018, at 10:49 AM, Kevin Rushforth  
> wrote:
> 
> Those are all excellent points. This suggests we might want to adopt a 
> general policy of "the current OpenJFX dev works with the latest released 
> OpenJDK plus the current OpenJDK under development" is the better way to go. 
> Otherwise it will be several years before OpenJFX can adopt, say, a new JDK 
> 12 or JDK 13 feature.
> 
> I note that this matches the model and spirit of the OpenJDK development. If 
> you want to get the latest and greatest features, use the latest feature 
> release. If you want stability, use a supported LTS release. Makes sense to 
> me.


Which can be much easier said than done.  I generally like to live near the 
bleeding edge… I *want to switch*, but we are still stuck on Java 8 (like I 
suspect most companies are) because of the very significant development effort 
to move to Java 9 or beyond.  Java 9 module's access controls were one thing, 
Java 11’s removal of some modules and development tools further broke the 
world.  Not to mention that good module support in the tool chain is still not 
available. We are waiting for the dust to settle, we need to wait for many 
dependencies and tools to catch up and become Java 11 compatible, then we have 
to try to migrate our own code and hope that all the dependency upgrades didn’t 
break things.  Basically we won’t even be able to start to migrate our code 
beyond Java 8 until next year (when Java 8 LTS ends).

I’ve already spent days trying to get code to build with Java 11 
(unsuccessfully). It’s the first time in the history of Java that I haven’t 
been able to upgrade the JRE with trivial effort.  Usually the only thing 
holding me back was waiting for Proguard to support the new class version. (And 
I could at least develop and test without obfuscation until it was ready.)

I am hoping that once we make the leap from Java 8 to Java 11, that further 
updates will be less painful.  If so, then I could agree that the latest 
OpenJFX can use the latest released JRE.

Unless you want to maintain a LTS release of OpenJFX in addition to the 
“current” version?

Scott


> 
> -- Kevin
> 
> 
> On 7/27/2018 7:35 AM, Johan Vos wrote:
>> I think we have to distinguish between the technical work done by OpenJFX 
>> and the distributions/support offered by companies; similar to the technical 
>> work in OpenJDK and the distributions/support offered by Oracle and others.
>> 
>> The technical work done here should imo be able to use all functionality 
>> offered by the latest released JDK (11/12/...)
>> 
>> I don't think there is a good reason on why the head-development of OpenJFX 
>> can not use the latest JDK release. If developers/companies want to switch 
>> to the latest and greatest OpenJFX release, they can also upgrade to the 
>> latest released OpenJDK.
>> 
>> And if there are company rules preventing this, well, that is a reason to 
>> consider commercial support.
>> I don't like to use my commercial hat in this list, but this is why we have 
>> JavaFX Enterprise support with Gluon: 
>> https://gluonhq.com/commercial-support-for-javafx/
>> Also, not that it is relevant on this list, but the revenues from commercial 
>> enterprise support allow us to spend resources on working on OpenJFX.
>> 
>> - Johan
>> 
>> On Fri, Jul 27, 2018 at 4:12 PM Kevin Rushforth > > >> wrote:
>> 
>>Hi Steve,
>> 
>> 
>>>I don't know if this discussion already comes up but I didn't
>>>found any related answers.
>>>Is there a self-defined goal about the compability of versions
>>>OpenJFX and the OracleJDK LTS versions?
>>>E.g. OpenJFX will be compatible to OracleJDK 11 until the next
>>>LTS version of Oracle will be released
>> 
>>That's an excellent question. While I might expect OpenJFX 12 to
>>stop running on JDK 10 at some point (JDK 10 is EOLed by JDK 11,
>>and dropping support for it would allow us to get rid of the old
>>swing interop implementation and build logic), having it run on
>>JDK 11 is a requirement: At a minimum we will need to run on the
>>latest released version at any point, since we are no longer
>>bundled. Beyond that, it's up for discussion among the OpenJFX
>>community: I can see value in allowing, say, OpenJFX 13 or 14 to
>>continue to run with JDK 11 LTS, but there is also a cost to doing
>>so, both in terms of testing and also in either avoiding new JDK
>>features or using reflection or other techniques to optionally use
>>them.
>> 
>>What do others think?
>> 
>> 
>>-- Kevin
>> 
>> 
>> 
>>On 7/27/2018 6:43 AM, Steve Hruda wrote:
>>>Hi Kevin,
>>>at the moment it's not really a use-case. I didn't used the jmods
>>>because I test if the maven artifacts could easier our life in
>>>case of maintaining different product versions.
>>>I love the easy 

Re: JavaFX 11 snapshots in maven sonatype

2018-07-08 Thread Scott Palmer
If separate Gradle processes produce the artifacts, there is probably a way to 
bring them together and (re-)publish them together in yet another project. 

Scott

> On Jul 8, 2018, at 8:38 AM, Johan Vos  wrote:
> 
> I don't think that will help, as the artifacts for the different platforms
> are not created inside the same gradle process. We don't do
> cross-compiling, so for each compileTarget a different machine and a
> different build process is used.
> Hence, I think we have to deal with separate publications anyhow, right?
> 
> - Johan
> 
>> On Sun, Jul 8, 2018 at 11:06 AM Kenzie Togami  wrote:
>> 
>> Hi Johan,
>> 
>>> It is very inconvenient, so if you know an easy way to get all snapshot
>> version to be equal, I would love to hear that.
>> 
>> I think that the varying snapshots versions probably occur because a
>> separate publication is set up for each `compileTarget`:
>> https://github.com/javafxports/openjdk-jfx/pull/83/files#diff-c197962302397baf3a4cc36463dce5eaR1564
>> I haven't used the Gradle maven-publish plugin yet but I think it could
>> work if you instead iterate over each target where the artifacts are
>> generated, which is the only place it's used anyways:
>> 
>> compileTargets { t ->
>>artifact project.tasks."moduleEmptyPublicationJar$t.capital"
>>artifact project.tasks."modularPublicationJar$t.capital" {
>>classifier "$t.name"
>>}
>> }


Re: Support additional video codec and container format

2018-06-25 Thread Scott Palmer
I don't want Oracle to add any of those formats.  I want them to make it so
*anyone* can add a new codec.  Then they don't have to worry so much about
which codecs to support.  The community can take care of that.

If Oracle is going to officially support another codec the only one worth
putting their effort into at this point is HEVC (H.265)

Scott

On Sun, Jun 24, 2018 at 10:49 AM Sverre Moe  wrote:

> I wanted to revive this discussion when I saw Java 9 has gotten
> upgraded GStreamer in JEP-257.
> Also Java 11 has an upgrade to GStreamer 1.14
> https://bugs.openjdk.java.net/browse/JDK-8199527
>
> The formats supported are very few:
>
> https://docs.oracle.com/javase/10/docs/api/javafx/scene/media/package-summary.html
>
> What does it take to implement support for these Video formats?
> It cannot be a license problem because Java 10 already has x264 as the
> Only supported video format.
>
> Is there any work scheduled to improve on this in JavaFX?
>
>
>
> Den søn. 10. sep. 2017 kl. 20:49 skrev Sverre Moe :
> >
> > Some very old issues for this kind of change
> > https://bugs.openjdk.java.net/browse/JDK-8091063
> > https://bugs.openjdk.java.net/browse/JDK-8091656
> >
> > One new comment on the latter issue suggesting to add new formats like
> > "Ogg/{Vorbis,Theora}, flac, matroska (MKV), Opus, VP8, 3GPP, GSM"
> >
> > This would be great to have on JavaFX. I seriously hope they would add
> it for Java 10 at least, or a later Java 9 update.
> >
> >
> >>
> >> Date: Fri, 8 Sep 2017 20:51:06 +1000
> >> From: John-Val Rose 
> >> To: Sverre Moe 
> >> Cc: openjfx-dev@openjdk.java.net
> >> Subject: Re: Support additional video codec and container format
> >> Message-ID: <51d7ca89-1d83-4e0f-a9f8-ef59a00b6...@gmail.com>
> >> Content-Type: text/plain;   charset=us-ascii
> >>
> >> +1
> >>
> >> > On 8 Sep 2017, at 19:05, Sverre Moe  wrote:
> >> >
> >> > Why is JavaFX not supporting open video container and codec?
> >> > From Java 9 VP6 is deprecated.
> >> >
> >> > The only relevant supported coded for JavaFX is H.264/AVC. The only
> other
> >> > alternative is VP6 which has been deprecated in Java 9.
> >> >
> >> > We cannot use H.264 without paying lisence fee for a commercial
> application.
> >> >
> >> > Support for Ogg Theroa/Vorbis should be considered, at least VP8
> and/or VP9
> >> > in place for the deprecated VP6. The MediaPlayer for Java 10 has not
> gotten
> >> > any changes either. I reckon it is too late for Java 9 to get new
> formats.
> >
> >
>


Re: Draft JEP for new Packaging Tool (replacement for javapackager)

2018-06-05 Thread Scott Palmer
Yes, my only comment was that if we can get a window up using standard Java
GUI frameworks fast enough, then the complexity of adding splashscreen
support to the launcher isn't justified.
Mario's example shows that is it 1-2 seconds to get a window up.  That is a
bit high.  If it was under 1s then I would suggest not bothering, it isn't,
so keep it on the list of desired features.

Scott

On Tue, Jun 5, 2018 at 8:21 AM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:

>  Sorry, perhaps it was I who misunderstood the debate..
>
> On Mon, Jun 4, 2018 at 4:06 PM, Michael Paus  wrote:
>
> > Maybe I misunderstood the question but to my opinion the real question is
> > whether the new java packager has to provide the support for a splash
> > screen
> > or not. This has nothing to do with the question whether applications
> > should
> > have a splash screen or not because if we find that todays Java is fast
> > enough
> > to display a simple window in less than a second or so, then the Java GUI
> > (Swing or JavaFX) could provide a splash screen itself. There is then no
> > need
> > for an additional mechanism provided my the packager.
> >
> > Am 04.06.18 um 16:44 schrieb Pedro Duque Vieira:
> >
> > Hi,
> >>
> >> I agree with Johan and others, a splash screen is valuable and needed.
> >>
> >> Microsoft applications that run on Windows itself (think Word, Excel,
> >> etc),
> >> they have a splash screen, Intelllij has a splash screen (it's swing
> based
> >> AFAIK), etc.. If a Microsoft application running on its own operating
> >> system needs a splash screen then chances are pretty high that there
> will
> >> be Java apps that'll need a splash screen.
> >>
> >> Cheers,
> >>
> >>
> >>
> >
>
>
> --
> Pedro Duque Vieira
>


Re: Draft JEP for new Packaging Tool (replacement for javapackager)

2018-06-04 Thread Scott Palmer
Nobody is arguing against splash screens.  I’m simply suggesting that the JVM 
startup is not slow enough that we need special handling of this in native code.

If Java can get a window displayed in under half a second there is no need for 
the added complexity to support a native splash screen in the launcher.

The idea that cinit code *can* be slow is not really the issue here unless it 
isn’t possible to get a window displayed quickly even when there is no 
significant initialization other than to get that window= shown.  Don’t put 
heavy initialization in the main class when you want a splash screen.  Use a 
pre-main class that shows the splash screen and calls the “real” main class.

It makes sense to understand if we have this problem before making a complex 
solution.

Scott


> On Jun 4, 2018, at 10:44 AM, Pedro Duque Vieira  
> wrote:
> 
> Hi,
> 
> I agree with Johan and others, a splash screen is valuable and needed.
> 
> Microsoft applications that run on Windows itself (think Word, Excel, etc),
> they have a splash screen, Intelllij has a splash screen (it's swing based
> AFAIK), etc.. If a Microsoft application running on its own operating
> system needs a splash screen then chances are pretty high that there will
> be Java apps that'll need a splash screen.
> 
> Cheers,
> 
> 
> -- 
> Pedro Duque Vieira



Re: Draft JEP for new Packaging Tool (replacement for javapackager)

2018-06-04 Thread Scott Palmer
If a Java window appears in less than half a second there is no point in adding 
the complexity of a native splash screen.

Scott

> On Jun 4, 2018, at 5:13 AM, Tom Schindl  wrote:
> 
> A splash screen has to be that instant that it IMHO makes no sense to
> time how long it takes to get the JVM and JavaFX up and running because
> it can never be as instant as a splash has to show up.
> 
> Tom
> 
>> On 04.06.18 01:06, Scott Palmer wrote:
>> Has anyone actually timed how long it takes to get a Java window on screen? 
>> I don’t think the delay is long enough to bother with a splash screen these 
>> days. 
>> 
>> Scott
>> 
>>> On Jun 3, 2018, at 4:22 AM, Tom Schindl  wrote:
>>> 
>>> That's why I requested that since a long time from the packager because
>>> a splash has to be part of the native launcher created.
>>> 
>>> The Eclipse-RCP-Launcher does exactly the right thing:
>>> * Show a static image (IIRC they use bmp)
>>> * Once the VM and UI-Toolkit is up replace that image with a window (SWT
>>> calls it Shell) so that you can go interactive showing videos,
>>> a progressbar, ...
>>> 
>>> Tom
>>> 
>>>> On 03.06.18 10:11, Mario Ivankovits wrote:
>>>> A preloader/splash-screen will/should also hide the JVM startup time.
>>>> 
>>>> Best regards,
>>>> Mario
>>>> 
>>>> 
>>>>> Am 03.06.2018 um 09:57 schrieb Tom Schindl :
>>>>> 
>>>>> On 01.06.18 19:42, Johan Vos wrote:
>>>>>> I'm not saying a preloader is really a requirement, but I know of a few
>>>>>> applications that are using it and benefiting from it.
>>>>>> 
>>>>>> The preloader functionality is more than just a splash screen, and I see
>>>>>> this valuable for instance when static initializers of classes that are
>>>>>> used in the main class may take a lot of time.
>>>>> 
>>>>> Then I'd argue that you can easily refactor your main-class ;-)
>>>>> 
>>>>> Tom
>>>> 


Re: Draft JEP for new Packaging Tool (replacement for javapackager)

2018-06-03 Thread Scott Palmer
Has anyone actually timed how long it takes to get a Java window on screen? I 
don’t think the delay is long enough to bother with a splash screen these days. 

Scott

> On Jun 3, 2018, at 4:22 AM, Tom Schindl  wrote:
> 
> That's why I requested that since a long time from the packager because
> a splash has to be part of the native launcher created.
> 
> The Eclipse-RCP-Launcher does exactly the right thing:
> * Show a static image (IIRC they use bmp)
> * Once the VM and UI-Toolkit is up replace that image with a window (SWT
>  calls it Shell) so that you can go interactive showing videos,
>  a progressbar, ...
> 
> Tom
> 
>> On 03.06.18 10:11, Mario Ivankovits wrote:
>> A preloader/splash-screen will/should also hide the JVM startup time.
>> 
>> Best regards,
>> Mario
>> 
>> 
>>> Am 03.06.2018 um 09:57 schrieb Tom Schindl :
>>> 
>>> On 01.06.18 19:42, Johan Vos wrote:
 I'm not saying a preloader is really a requirement, but I know of a few
 applications that are using it and benefiting from it.
 
 The preloader functionality is more than just a splash screen, and I see
 this valuable for instance when static initializers of classes that are
 used in the main class may take a lot of time.
>>> 
>>> Then I'd argue that you can easily refactor your main-class ;-)
>>> 
>>> Tom
>> 


Re: Draft JEP for new Packaging Tool (replacement for javapackager)

2018-06-01 Thread Scott Palmer



> On Jun 1, 2018, at 5:01 AM, Tom Schindl  wrote:
> 
> On 01.06.18 08:01, Michael Ennen wrote:
>> Re-familiarizing myself with what javapackager offers, it seems the
>> following JavaFX related
>> features are present:
>> 
>> 1.) The conversion of CSS to binary CSS
>> 2.) The ability to specify a preloader
>> 3.) the ability to specify the JavaFX Application class
>> 
>> The first one seems like a bit of feature-creep and could be replaced by
>> some other build
>> tool if third party developers really need that feature. They could
>> probably even use something
>> like maven-exec-plugin to manually call such a converter. Let's set this
>> one aside, then.
>> 
>> The second and third one are important for correctly launching a JavaFX
>> application. I would
> 
> on 2.: What is a preloader good for if you launch a local application?
> IMHO it only really made sense for Webstart
> 
> on 3. Why? All you need to do is to provide a main-method and you are
> good to go.

+1, I have only used a main method that simply calls launch(args).  I never 
understood why there was a need for special launching of JavaFX apps.

At one point I thought of using a preloaded for a splash screen because 
sometimes I have an application that needs to initialize a lot of plugins, so 
there is a significant startup time, but it isn’t worth it.  The main method 
launches fast enough.


Scott

Re: OpenJFX status update

2018-05-16 Thread Scott Palmer
It needs a lot of work.  I’m reminded as a see all the issues I’ve reported 
against it are being reassigned today.

Despite the issues, Javapackager was one of the best things to happen for Java 
deployment in many years.  I’m kinda bummed that it didn’t make it to OpenJDK.

jlink isn’t really usable for me, as it requires everything to be 100% 
modularized, and that is next to impossible to achieve if you have any external 
dependencies.

There is an issue to have jlink create a native launcher though:
https://bugs.openjdk.java.net/browse/JDK-8182555 


(You would think the javapackager guy and the jlink guy would talk to each 
other at some point… if such people are still around.)

Cheers,

Scott


> On May 16, 2018, at 4:11 PM, Michael Ennen  wrote:
> 
> Alright great, no complaints from me then :).
> 
> On Wed, May 16, 2018 at 1:08 PM, Kevin Rushforth  
>> wrote:
> 
>> Yes, the source code for javapackager is fully open source.
>> 
>> -- Kevin
>> 
>> 
>> 
>> On 5/16/2018 1:05 PM, Michael Ennen wrote:
>> 
>> Is the source code for javapackager fully open source?
>> 
>> Thanks.
>> 
>> On Wed, May 16, 2018 at 10:08 AM, Kevin Rushforth <
>> kevin.rushfo...@oracle.com > wrote:
>> 
>>> The javapackager was removed from the Oracle JDK along with JavaFX (and
>>> has never been part of OpenJDK). It isn't included with the standalone
>>> JavaFX bundles, and doesn't really fit in a standalone FX release.
>>> 
>>> We are looking at the possibility of providing a replacement packaging
>>> tool in OpenJDK.
>>> 
>>> -- Kevin


Re: Proposal For Inclusion of Robot and ParametersImpl in the Public API

2018-03-24 Thread Scott Palmer


> On Mar 23, 2018, at 5:50 PM, Michael Ennen  wrote:
> 
> Kevin,
> 
> I believe I followed all of your suggestions, except the one with a
> re-usable WritableImage.
> If you want me to implement that as well, I can, but you seemed unsure
> about the necessity
> of it.

I think it should be included to reduce garbage generated in a case where 
repeated captures is used.  Such as a desktop sharing application, a screen 
recorder, etc.
It would also be consistent with the node.snapshot API.

In fact, I would just have the version that takes a WriteableImage and match 
the behaviour of node.snapshot.

Scott



Re: Windows Build setupTools

2017-12-21 Thread Scott Palmer
One of the reasons I would like to eliminate Cygwin is that I believe it causes 
more problems than it is worth.  For example, lat time I check, there was a 
bunch of code in the build scripts to hack paths because Cygwin apparently 
wants non-Windows paths on Windows.  It’s the “let’s pretend we aren’t on 
Windows and make a mess” strategy employed by Cygwin that I find 
counter-productive.  (As a developer, I do like having common Un*x tools 
installed, but I prefer Windows ports of those tools that understand how to 
properly run on Windows instead of creating some virtual unix environment that 
doesn’t quite fit.)

I suspect a lot more build logic could be done within the Gradle scripts rather 
than using external tools.  That would result in a more portable build 
experience with less places for things to go wrong.

Regards,

Scott

> On Dec 21, 2017, at 12:14 PM, jav...@use.startmail.com wrote:
> 
> I did not try Tom's build instructions however I can contribute that having 
> Cygwin on Windows 7 and following the build instructions as posted on the 
> JavaFX build instructions page is not suffcient to result in a successful 
> build. 
> 
> The exact error messages I was receiving I posted earlier .
> 
>  
> On Thursday, December 21, 2017 3:08 AM, Michael Ennen  
> wrote:
>  
>> Thanks for the tip, Tom. I understand that Cygwin is a dependency of
>> building on Windows but didn't
>> know that the properties are only configured on a cygwin shell.
>> I have a pseudo-goal of removing the Cygwin dependency from building
>> OpenJFX on Windows and
>> I wonder why Cygwin is necessary for setupTools to work? I see other
>> obvious places in the build
>> files that would only work on Cygwin, but am unclear as to why the
>> properties would not be set
>> in cmd.exe or Powershell.
>> Thanks again for the clarification.
>> On Thu, Dec 21, 2017 at 1:04 AM, Tom Schindl 
>> wrote:
>>  
>>> Hi Michael,
>>> I did not had to setup any special variables and documented my steps at
>>> https://github.com/BestSolution-at/openjfx-build.
>>> I had trouble myself initially but the reason was that I ran the "gradle
>>> sdk" command from within a MSDOS-Shell but you really need to run it within
>>> cygwin.
>>> Tom
>>> On 21.12.17 06:40, Michael Ennen wrote:
>>>  
 Some people were reporting that Windows builds are difficult to setup.
 I think this is due to the fact that the call to setupTools in
 buildSrc/win.gradle
 is in fact not working correctly.
 Invoking buildSrc/genVSproperties.bat directly prints the correct
 properties.
 However adding some debugging to setupTools it is clear that something is
 very wrong
 with it. This is the result:
 WINDOWS_VS_DEVENVDIR=
 WINDOWS_VS_DEVENVCMD=/VCExpress.exe
 WINDOWS_VS_VCINSTALLDIR=
 WINDOWS_VS_VSINSTALLDIR=
 WINDOWS_VS_MSVCDIR=
 WINDOWS_VS_INCLUDE=
 WINDOWS_VS_LIB=
 WINDOWS_VS_LIBPATH=
 WINDOWS_VS_PATH=;
 WINDOWS_VS_VER=120
 WINDOWS_SDK_DIR=
 WINDOWS_SDK_VERSION=
 This is the reason people are needing to hard-code values for the
 properties
 below the call to setupTools.
 I am trying to debug what is actually wrong with setupTools but so far not
 making much
 progress. I tried this on my local Windows 10 machine and Appveyor VMs and
 the result
 is the same. I also read at least two mails in this list about needing to
 hard-code the
 properties, I am assuming it is for the same reason.
 I will try and figure out the reason but wanted to at least make this
 issue
 more concrete.
  
>> --
>> Michael Ennen



Re: Building OpenJFX.

2017-12-19 Thread Scott Palmer


> On Dec 19, 2017, at 5:13 PM, Mario Torre <neugens.limasoftw...@gmail.com> 
> wrote:
> 
> 2017-12-19 23:04 GMT+01:00 Scott Palmer <swpal...@gmail.com>:
>> The project should be configured to use the Gradle Wrapper, so the correct 
>> version of Gradle is used automatically.
> 
> This is not an option for Linux distributions and is not an option for
> many people using them. We need to be able to produce a build with an
> all local toolchain.

The availability of the Gradle Wrapper does not mean you have to use it though. 
 It would be helpful for those that can use it, at least if they suspected a 
Gradle incompatibility to be contributing to their builds problems.  I have 
found that most Gradle versions since 3.x have worked fine on my projects 
without requiring any tweaks.

Regards,

Scott



Re: Building OpenJFX.

2017-12-19 Thread Scott Palmer
The project should be configured to use the Gradle Wrapper, so the correct 
version of Gradle is used automatically.
https://docs.gradle.org/current/userguide/gradle_wrapper.html 


There was some concern about checking in the gradle-wrapper.jar file, and 
potential licensing issues.  While I doubt such issues are “real” I understand 
that you have to deal with Oracle lawyers.  Perhaps a solution then is to 
configure the wrapper via a setup step to run the wrapper task with any version 
of gradle that can handle it, then run the gradlew script that it generates.

e.g.
build.gradle contains:
task wrapper(type: Wrapper) {
  gradleVersion = '4.3'
}

one-time setup:
gradle wrapper

run the build:
gradlew

Gradle bumps should be able to happen any time without causing issues.  Gradle 
becomes just another dependency that is automatically fetched. A simple check 
to make sure the Gradle version is okay can be coded into the build script, 
e.g. something like:

def blessed_gradle_version = '4.3'
task wrapper(type: Wrapper) {
  gradleVersion = blessed_gradle_version
}
if (project.gradle.gradleVersion != blessed_gradle_version) {
  println "Build expects ${blessed_gradle_version} but found 
${project.gradle.gradleVersion}\n Run 'gradle wrapper', then use 'gradlew'"
} else {
  apply from: 'real_build.gradle'
}

Gradle incompatibilities should be rare anyway.

What I would really like to see, and I know I’m asking for a lot, is the 
elimination of the Cygwin requirement and the use of the Gradle native plugin 
for the native code (maybe we can exclude WebKit from that for now)
You shouldn’t need Ant either.

It should be easy to build without WebKit and have pre-built WebKit binaries 
pulled in like any other dependency instead, based on a build property. E.g. 
gradlew -PusePrebuiltWebKit=true

Regards,

Scott

> On Dec 19, 2017, at 4:17 PM, Kevin Rushforth  
> wrote:
> 
> Building WebKit is challenging, to be sure. I hope to enlist the help of some 
> of our WebKit team members to review (and contribute to) update build 
> instructions to help make it a little less painful, but it is still a 
> challenge.
> 
> As for the moving version of gradle, we so far have settled on a specific 
> version for each release family: gradle 1.8 for JDK 8u, 3.1 for JDK 9, and 
> 4.3 for JDK 10. We don't tend to bump it.
> 
> Thanks for the feedback.
> 
> -- Kevin
> 
> 
> Mario Torre wrote:
>> For me the most intricate part is about building the webkit based
>> code, especially on RHEL/CentOS. I admit I didn't try with the very
>> latest code drop though. The moving version of Gradle is also an
>> issue, since we try to use a stable toolchain on those OSes.
>> 
>> Cheers,
>> Mario
>> 
>> 2017-12-19 21:11 GMT+01:00 Phil Race :
>>  
>>> In the "innovation" email thread it was suggested that one obstacle to
>>> getting involved and contributing to OpenJFX is just building it.
>>> 
>>> So what are the top one or two pain points with building OpenJFX today ?
>>> 
>>> - Insufficient or out-dated build docs ?
>>> - Tool-chain configuration problems - platform-specific or otherwise ?
>>> - Needing to do a JDK build as well (JDK 9 and later) ?
>>> - Something else ?
>>> 
>>> And having identified your pain point(s), what do you think would be a
>>> solution ?
>>> 
>>> -phil.


Re: javapackager feedback and questions

2017-11-30 Thread Scott Palmer
I’m using javapackager to generate native installers for several services and 
GUI applications. I would be using it for some command line tools as well, but 
it doesn’t yet support “console” applications on Windows. I.e. you can’t make 
javapackager with javapackager. I’ve filed an issue for that already (it was 
closed as won’t fix, but thankfully it was reopened)

Javapackager is one of the most useful tools in the JDK, but it is mostly 
undocumented and has many usability issues.
IMO, it tried to do way too much. The only thing it ever needed to do was the 
-deploy option.

I run javapackager two ways, always from Gradle scripts, either via the javaFX 
Gradle plugin, or as an Exec task.

The ability to have secondary launchers is great.

The customization options for installers needs some work. I’ve filed several 
issues (and I could file more). E.g. background images for macOS .dmg must be 
different from background images used in macOS .pkg as they are serving 
entirely different purposes. Including custom resources in subdirectories is 
difficult and/or broken depending on the version of javapackager used (v9 is 
broken).
On Windows .msi component rules are not followed making upgrades problematic. 
Install folders should be customizable by supplying custom wix files, etc.

On Linux services should be handled with systemd or sysctl. (I can’t remember 
which is preferred at the moment, but I know it didn’t use what I needed.)

I really like that we have javapackager and feel it is a very important 
addition to the JDK.  

I too would love if it could build for multiple platforms from a single 
platform, but I honestly don’t see that happening. It isn’t worth the trouble 
or effort - things like making a HFS+ .dmg for macOS from Windows isn’t 
realistic. We do NOT want some custom non-native installer (Though a .zip of an 
app bundle might work.)  You would also need the native bits of the JRE for 
each platform anyway. It would be possible to have those files available on any 
platform, but the tools to build .deb, .rpm, .dmg, .msi, etc. are just never 
going to be available everywhere.

Scott

> On Nov 30, 2017, at 7:16 PM, Kevin Rushforth  
> wrote:
> 
> Hi Michael,
> 
> We realized that the javapackger CLI JEP wasn't quite ready, and was out of 
> scope for JDK 10 anyway, so we withdrew it in order to file a new JEP later.
> 
> Related to this, we are soliciting input as to how people are using the 
> javapackager (see Victor's question below).
> 
> So we'd love to hear how you and others are using it, and for what kind of 
> applications.
> 
> -- Kevin
> 
> 
> Michael Hall wrote:
>>> On Nov 29, 2017, at 5:18 PM, victor.droz...@oracle.com wrote:
>>> 
>>> Hi, Mani.
>>> 
>>> Thanks for providing the feedback!
>>> We will consider adding more examples and more details in the docs as you 
>>> proposed(there is an arg named jvmOptions but that's not mentioned in the 
>>> table).
>>> Looks like there is a bug when you specify systemWide=true on the MacOSX in 
>>> non-gui mode. Can you provide more details about that (like full cmd line)?
>>> Actually, if you want you can clone the repo:
>>> http://hg.openjdk.java.net/openjfx/10-dev/rt/
>>> (hg clone http://hg.openjdk.java.net/openjfx/10-dev/rt/)
>>> and help to improve javapackager. Or you can just create Enhancements for 
>>> deploy/packager, as it's not always clear what users expect.
>>> 
>>>
>> 
>> Why was JEP 311 [1] Closed/Withdrawn?
>> 
>> [1] http://openjdk.java.net/jeps/311
>> 
>>  


Please Re-Open JDK-8169596

2017-11-27 Thread Scott Palmer
https://bugs.openjdk.java.net/browse/JDK-8169596

There is no reason to preclude creating command-line tools with Java.  This
restriction makes it impossible to create programs like javapackager with
javapackager.

Scott


Multiselection in a TreeView

2017-10-12 Thread Scott Palmer
Try it.  It has a lot of issues.
- SelectedItems ListChangeListener misses “Remove” notifications
- IndexOutOfBoundsExceptions
- Selection of item by clicking on the collapse-node widget

See https://bugs.openjdk.java.net/browse/JDK-8189228

Scott

Re: WebView and WebGL

2017-09-09 Thread Scott Palmer
If I’m remembering correctly, I think the another factor for why WebGL wasn’t 
included is that the rendering layer of WebKit was done on top of JavaFX.  That 
allows it to integrate nicely with the all the other JavaFX rendering.

Personally I wish that time wasn’t wasted (IMO) on the existing 3D support and 
instead proper OpenGL support was done for JavaFX - *outside* of WebKit.  I 
think that might have required solving another problem - integrating a native 
rendering surface into the scene graph.  That would have allowed me to solve 
other problems, such as showing realtime video from a camera or other image 
sources, that the existing media API doesn’t support.

My issue requesting extensible media support is coming up on its 9-year 
anniversary:
https://bugs.openjdk.java.net/browse/JDK-8091063
(It’s closed now as it is marked as a duplicate of issues that were created 
later, even though those issues don’t adequately cover what is required.)


Frankly I have very little use for WebKit in a JavaFX application (other than 
for displaying help pages or something).  If I’m going to make a web app, I 
will just make a web app.  JavaFX would only serve to make a web app less 
accessible.   I would of course never make a web app where a proper desktop app 
is more appropriate, because they always suck compared to apps that aren’t 
crippled by running in a browser.  :-)


Scott


> On Sep 9, 2017, at 11:06 AM, Mike Hearn  wrote:
> 
> I'm not on the FX team, but I'd suggest just starting work on it and see how 
> far you get. You might duplicate some of the research the FX engineers are 
> doing but you also might not, or you might find yourself being able to 
> influence the direction of the project with unique input.
> 
> If you can make WebGL work in WebKit, I guess it's not much harder to expose 
> an eGL binding via JavaFX itself as WebGL is basically eGL for the web.
> 
> I'd like to see GL support in JavaFX, if only because I enjoy blinging apps I 
> write, including business apps! The embedded video player is invaluable for 
> this sort of thing too.
> 
> 1. Why wasn't WebGL support implemented from day zero given that WebKit 
> supports it?
> 
> I am going to take a stab at these answers based on my relatively poor 
> understanding of how JavaFX works. Answers worth what you paid for them.
> 
> I'm going to guess that the answer is Windows. 




Re: WebView and WebGL

2017-08-26 Thread Scott Palmer
+1

... to Any high performance way to get images from native code to the screen in 
a JavaFX app.  I filed an enhancement request many years ago for a method to 
supply portions of the media pipeline for the media player APIs. 

I've also been asking for some way to get at a native surface context. Be it 
DirectX, OpenGL, Metal,... even just a native window handle.


Scott

> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom  wrote:
> 
> Hi Michael, all,
> 
> Just want to state my support for Michael's "Direct backed WritableImage".
> Having a way to do natively-backed rendering is IMO the most important
> feature still missing from FX. This is an area where QT is still way ahead
> with it's OpenGL/OpenGL ES integration.
> 
> Having something like a direct-WritableImage implementation would also make
> it easier to implement a video viewer using native decoder libs. Personally
> I find this approach much more powerful than the existing FX 3D and media
> streaming features, which are (especially 3D) limited in their
> capabilities.
> 
> I will be at JavaOne this year, so if there is any interest in meeting up
> and talking JavaFX I'm in!
> 
> Best regards,
> 
> Sten Nordström
> 
>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer  wrote:
>> 
>> Hi Jonathan, hi all,
>> 
>> I would like to bring up the "WritableImage backed by DirectBuffer"
>> discussion again:
>> 


Re: javapackager - partially self-contained apps in JDK 9

2017-04-25 Thread Scott Palmer

> On Apr 11, 2017, at 1:43 PM, Alan Snyder  wrote:
> 
> I have run into a problem in moving my macOS apps from JDK 8 to 9. The issue 
> relates to using MySQL via JDBC.
> The connector class name is fixed. The class is loaded using Class.forName(). 
> However, there can be different versions
> of the connector in different JAR files, and the proper version might need to 
> be synced with the currently installed version
> of MySQL.
> 
> In JDK 8, I used the extension mechanism to load the MySQL connector JAR 
> rather than building this JAR into the bundled app.
> My thinking was that the connector might need to be updated in sync with the 
> database and I should not have to rebuild apps to do that.
> 
> In JDK 9, the extension mechanism is gone. I have not found any way to 
> achieve the equivalent effect. It seems that javapackager
> controls the setting of the CLASSPATH. I have not found an option that would 
> allow me to extend the CLASSPATH with a directory
> where the connector JAR could be found. Is there a way to do this?

My application ran into classpath issues because it tried to dynamically add 
plugins to the classpath and that broke on Java 9.  To work around it I created 
an agent so I could get access to the java.lang.Instrumentation interface to 
add to the classpath.  You might try that approach.  It’s ugly, but better than 
reflectively accessing private fields of URLClassLoader, which doesn’t work for 
Java 9 :-)

Scott



Re: Is a Desktop Experience on ARM with X11 Possible?

2017-02-10 Thread Scott Palmer
Hi Johan,

Excellent! Do you have a build or instructions somewhere?

Thanks,

Scott

> On Feb 10, 2017, at 4:03 AM, Johan Vos <johan@gluonhq.com> wrote:
> 
> Hi Scott,
> 
> I actually have this working, leveraging the new mesa driver for the Pi.
> It is using monocle and ES2 and it integrates very well with the X11 system 
> on the Raspberry Pi.
> 
> - Johan
> 
> On Thu, Feb 9, 2017 at 8:19 PM Scott Palmer <swpal...@gmail.com 
> <mailto:swpal...@gmail.com>> wrote:
> Just wondering if there are some options for building OpenJFX for
> embedded ARM such that it behaves like it does on x86 Linux with X11.
> I mean with actual decorated windows instead of just  lumping
> everything onto the frame buffer or a single window.
> 
> Is this currently possible?
> 
> 
> Scott



  1   2   3   >