Integrated: 8214158: Implement HostServices.showDocument on macOS without calling AWT

[Michael Paus]

On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus  wrote:

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

This pull request has now been integrated.

Changeset: f3c72b93
Author:Michael Paus 
Committer: Kevin Rushforth 
URL:   
https://git.openjdk.java.net/jfx/commit/f3c72b936b5c6c36eed022855d34570b1b9d3597
Stats: 112 lines in 5 files changed: 110 ins; 1 del; 1 mod

8214158: Implement HostServices.showDocument on macOS without calling AWT

Reviewed-by: kcr, arapte

-

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT [v5]

[Michael Paus]

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

Michael Paus has updated the pull request incrementally with one additional 
commit since the last revision:

  Fixed two minor formatting issues

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/634/files
  - new: https://git.openjdk.java.net/jfx/pull/634/files/4e510dec..24ceab1c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=634=04
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=634=03-04

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

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT [v4]

[Michael Paus]

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

Michael Paus has updated the pull request incrementally with one additional 
commit since the last revision:

  Move test to subfolder HostServices

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/634/files
  - new: https://git.openjdk.java.net/jfx/pull/634/files/f2f70d60..4e510dec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=634=03
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=634=02-03

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

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT [v3]

[Michael Paus]

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

Michael Paus has updated the pull request incrementally with one additional 
commit since the last revision:

  Fix whitespace errors

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/634/files
  - new: https://git.openjdk.java.net/jfx/pull/634/files/ad9f268f..f2f70d60

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=634=02
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=634=01-02

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

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT [v2]

[Michael Paus]

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

Michael Paus has updated the pull request incrementally with one additional 
commit since the last revision:

  Add test

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/634/files
  - new: https://git.openjdk.java.net/jfx/pull/634/files/85654e56..ad9f268f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jfx=634=01
 - incr: https://webrevs.openjdk.java.net/?repo=jfx=634=00-01

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

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT

[Michael Paus]

On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus  wrote:

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

To answer your questions:
1. I have no idea about LSOpenURLsWithRole. I am not a Mac developer.
2. I have manually tested the change:

Button showHtml = new Button("HTML");
showHtml.setOnAction(e -> {this.getHostServices().showDocument(new 
File("data/test.html").toURI().toString());});

Button showTxt = new Button("TXT");
showTxt.setOnAction(e -> {this.getHostServices().showDocument(new 
File("data/test.txt").toURI().toString());});

Button showCsv = new Button("CSV");
showCsv.setOnAction(e -> {this.getHostServices().showDocument(new 
File("data/test.csv").toURI().toString());});

The code fragment above reliably opens the HTML document in Firefox (my default 
browser), the text document in BBEdit (my default text editor) and the CSV 
document in LibreOffice (my default Excel :-)

This also works if you just use the plain strings without conversion to an URI.

Here are the printed Java/FX version strings for completness:

java.runtime.version: 18-ea+16-926
javafx.runtime.version: 18-internal+0-2021-09-28-174132

-

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

Re: RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT

[Michael Paus]

On Tue, 28 Sep 2021 16:06:30 GMT, Michael Paus  wrote:

> Fixes the issue by using the "open" command as discussed before.
> See: https://bugs.openjdk.java.net/browse/JDK-8214158

First of all. Shall I follow the bot request above and create a new pull 
request? Wouldn't we loose the discussion here then?

-

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

RFR: 8214158: Implement HostServices.showDocument on macOS without calling AWT

[Michael Paus]

Fixes the issue by using the "open" command as discussed before.
See: https://bugs.openjdk.java.net/browse/JDK-8214158

-

Commit messages:
 - Remove dependency on java.awt.Desktop

Changes: https://git.openjdk.java.net/jfx/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jfx=634=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8214158
  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jfx/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jfx pull/634/head:pull/634

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

Re: RFR: 8090547: Allow for transparent backgrounds in WebView [v6]

[Michael Paus]

On Fri, 27 Aug 2021 17:01:00 GMT, Jose Pereda  wrote:

>> Currently, `WebPage` has already a public `setBackgroundColor()` method, but 
>> the class is not public. Therefore, public API is needed in `WebView` to 
>> allow developers access to it.
>> 
>> In line with the `fontSmoothingType` property, this PR provides public 
>> support for setting the background color of a WebPage, by adding a 
>> `pageFill` property, and a CSR is required.
>> 
>> The color for the background, that can be opaque, transparent or with any 
>> level of opacity, can be set via code or via CSS using `-fx-page-fill`.
>> 
>> Unit tests and a system test are provided.
>
> Jose Pereda has updated the pull request incrementally with one additional 
> commit since the last revision:
> 
>   Use color to int32 converter instead of hash

Always referring to Int32 is very vague and does not provide any information 
because this information is kind of obvious from the argument. It would be 
clearer to say RGBA (or whatever your assumption is) because that might help 
avoid confusion about which color component ordering you actually expect in 
your Int32.

-

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

Re: Layering JavaFX onto an external rendering context

[Michael Paus]

Why don't you just give it a try?

I'd start with the native PixelBuffer option first because it is 
relatively simple and the performance is sufficient for most use cases. 
There is, of course, an overhead caused by the GPU -> CPU -> GPU memory 
transfer but it is not so bad if done right. I've been able to interface 
a JavaFX application with the external VLC video player that way. I 
could watch 4K videos without a problem and without stressing the CPU 
too much. I do not even have a dedicated GPU in my Mac Mini - just the 
internal Intel graphic. The nice thing about this approach is that the 
maximum overhead is constant. It depends only on your hardware and the 
size of your rendering area but not on the complexity of your rendering.


Another advantage is that this approach is fully integrated into JavaFX. 
This means you can do anything with the rendering you can do with a 
JavaFX ImageView. E.g., drawing something on top of the rendering via 
JavaFX costs you nothing. Even double-buffering is possible if you know 
how to do that.


And if this is not enough for you, there still is DriftFX which avoids 
this GPU -> CPU -> GPU memory transfer but is a bit more ambitious to 
handle. So I would keep that in mind as an option if necessary.


Michael

Am 07.03.21 um 13:22 schrieb Neil C Smith:

Hi,

A few comments from my perspective here, mainly coming from
frustration at the number of times I've had to tell clients or users
that JavaFX isn't a viable option for them ..

On Sat, 6 Mar 2021 at 12:22, Mark Raynsford  wrote:

there is a
  combinatorial explosion of possibilities with regards to which
  rendering API the _user_ might be using, and which rendering API
  JavaFX might be using (if any!).

I agree that's a difficult one, but also surely not an insurmountable
one?!  There are precedents around Java APIs that provide querying and
access to optional support on a platform by platform basis.  A library
integrating JavaFX with some other platform / renderer specific API is
always going to have to handle the situation by either failing
gracefully or falling back to a less performant alternative.


Traditional stateful APIs like
  OpenGL make it far too easy for external code to screw up the
  rendering context anyway, so exposing JavaFX's own context would
  be a bad idea.

I remain of the view that this shouldn't really be that concerning?!
It's a bug in the library if it does so.  The current PixelBuffer API
already allows enough access for a library to *really* screw up the
rendering context, by bringing the whole thing crashing down.  But,
concurrency issues aside, adding that access has been a real boon.
With access comes responsibility.


JavaFX _does_ have a software renderer. What if we could have JavaFX
work with entirely software rendering into an offscreen BufferedImage?

Why BufferedImage?  What about a reuse / extension / parallel of
PixelBuffer?  That could allow a range of implementation and the
potential for using renderers that can output without a visible window
to do this while at least keeping all pixel data off heap?

Best wishes,

Neil

Re: JavaFX 15 with Java 14?

[Michael Paus]

The JavaFX versions are not directly related to the Java versions.
So you can use JavaFX 16-ea on Java 11+. It is however advisable
to always use the latest version of JavaFX and an as late as possible
Java version >= 11.

Am 05.02.21 um 18:07 schrieb Davide Perini:

Hi all,
is it safe to use JavaFX 15 with Java 14?

How JavaFX is related to Java version?

Thanks
Davide

Re: Make javafx.controls open and community-driven

[Michael Paus]

1+

Am 02.02.21 um 15:12 schrieb Pedro Duque Vieira:

Hi,

Although I don't agree with everything said here at the start of this
thread, I agree with the base idea that JavaFX would benefit from being
more open than it is currently. It's something I've already said here in
this mailing list and since it's been a while and that discussion probably
already got forgotten I'll add the comments to this thread again.

Not even just the controls case but more hooks to extend JavaFX just
generally by adding API that allows for that and making things less
private/final/etc. It would be great to be able to extend more parts of
JavaFX in a library independent way (i.e. by creating your own library that
extends some parts of JavaFX in more fundamental cool way).
Besides what was already said about controls, here's another example:
wouldn't it be great for the community to be able to create a library that
could extend the CSS parser by adding animations, layout support, etc, etc.
One could argue, why don't you just contribute a PR to the JavaFX code base
that does just that (adds animation support to CSS, or something less
trivial like that)? I'd say that that process is too lengthy and often out
of possibility for an individual developer that wants to improve JavaFX but
doesn't have time to do it that way.

I see the advantage of exposing less of the internals and why the JavaFX
team decided to do it. Many of the same guys that developed JavaFX were
part of the Swing team which were bothered by the inverse situation, i.e.
being too open (which also can have its disadvantages).
Weighing in the pros and cons, I still think there's a bigger advantage in
being more open than closed. This hinders the capacity for the community to
create libraries that extend JavaFX in new and fundamental ways without
having to fork JavaFX.
And this is more of a reality now that the JavaFX team is smaller (than the
original team) and hence has less capacity to keep improving and adding
features to JavaFX which means it has to rely more on the community.

I also agree with the process of submitting a bug and following upon it,
commenting, etc. Ideally it should be easier. That's something that has
also been brought up before.

Anyways, this mail is not meant to put down the guys working on
JavaFX, there are no perfect toolkits, each one has its downfalls. Think it
more like throwing in ideas and sharing my experience of using JavaFX for
creating libraries and applications.

Re: RFE: Shape Intersection

[Michael Paus]

I just mentioned JTS in a tweet myself 
(https://twitter.com/MichaelPaus/status/1351133904409915395)
but I think it would be a mistake to integrate that into JavaFX for 
various reasons. The main problem is
that Java never provided and used a graphics system independent geometry 
and math library. That's why
I like JTS because it is not tied to any specific graphics system and 
therefore it is much easier for me to
get my code running on different graphics systems. The latest being 
Jetbrains Compose and Skija.

Michael

Am 18.01.21 um 12:57 schrieb Kay, Jim:

I have used the JTS library (https://github.com/locationtech/jts) a lot over 
the years; this is my 'go to' library for all 2D geometry routines. It is very 
extensive and very well written by it’s main author Martin Davis. This library 
has entities such as Geometry, LineString, Polygon etc and shows how to do all 
geometric operations such as: intersect, intersection, difference, union, 
touches, overlaps etc.
It would be great to incorporate this type of library into JavaFX. I know it 
would require a bit of a rewrite but I think it would be worth it!
Jim Kay

-Original Message-
From: openjfx-dev  On Behalf Of Nir Lisker
Sent: 18 January 2021 11:42
To: Dirk Lemmermann 
Cc: OpenJFX 
Subject: Re: RFE: Shape Intersection

If this is to be implemented in JavaFX, then it's better to do (not tested):

1. Extract the intersection computation from Shape.intersect

private static Area intersectionArea(Shape shape1, Shape shape2) {
 Area result = shape1.getTransformedArea();
 return result.intersect(shape2.getTransformedArea());
}

2.  Shape.intersect becomes

public static Shape Shape.intersects(Shape shape1, Shape shape2) {
 var intersectionArea = intersectionArea(Shape shape1, Shape shape2);
 return createFromGeomShape(intersectionArea);
}

3. Add the new method Shape.intersects

public static boolean Shape.intersects( Shape shape1, Shape shape2) {
 var intersectionArea = intersectionArea(Shape shape1, Shape shape2);
 return !intersectionArea.isEmpty();
}

Regardless, I wonder why the geometry methods were implemented as static 
methods. Why not shape1.intersect(shape2)? I assume the new method should 
follow these, but on a clean slate I think I would have used the non-static 
approach.

Another thing I would think about is whether it makes sense to just one method or is it a 
part of a more comprehensive shape geometry bundle. Is "intersects?" the only 
question we would like to ask?

- Nir

On Mon, Jan 18, 2021 at 12:12 PM Dirk Lemmermann 
wrote:


I just noticed that there is no „intuitive“ API to check whether two
shapes intersect with each other. The only way (I think) to do it is
as
follows:

Shape.intersect((Shape) child, circle).getBoundsInLocal().getWidth()
!= -1

If this is indeed the case I would like to propose that a method shall
be added called „boolean Shape.intersects(Shape,Shape").

See also:
https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com
_questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx
=DwIFaQ=ukT25UmkSFgENae3bmQPWw=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1
AetrfAv2Mw=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y=DRGfselPcMM
lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8=
<
https://urldefense.proofpoint.com/v2/url?u=https-3A__stackoverflow.com
_questions_15013913_checking-2Dcollision-2Dof-2Dshapes-2Dwith-2Djavafx
=DwIFaQ=ukT25UmkSFgENae3bmQPWw=4CcGGNkvpQC43k2S_CRiSDUcCYYGpfGF1
AetrfAv2Mw=p3Mxo9ouTmwb0rTqUVuKSgB0UwSHVVoF-Q9F0D_Kr_Y=DRGfselPcMM
lUyRnLx7wTx4S243tMuSxGIBFhqNKKy8=
Dirk

Re: list digest

[Michael Paus]

You can find the archives here:
https://mail.openjdk.java.net/pipermail/openjfx-dev/

Am 20.12.20 um 21:48 schrieb Chuck Davis:

I just joined the list but I can't find a link to a digest of past activity.

I'm specifically interested in discussions regarding TableView.  Does
anyone know where to find the list digest?

Thanks.

Re: GraphicsContext and export to vector format files

[Michael Paus]

At this point I would disagree with you. Doing so would just
result in a sever performance hit. I will not go into the details
here because that idea is out of reach anyway.

Am 02.11.20 um 15:42 schrieb Bruce Johnson:

And if you want to think of even further advances (which I’d avoid at this 
point because I’d like this to get done in a useful time frame), I’ve often 
thought that all JavaFX scene drawing should use the Canvas GraphicsContext.  
So with the changes I’m suggesting that would allow export of the complete 
scene graph to another device (vector graphics files etc.)

Bruce



On Nov 2, 2020, at 9:17 AM, Michael Paus  wrote:

Hi,
I very much like the idea in general but I think it falls too short.
Such an interface should not be tied to any existing graphics
framework. Instead it should be just pure Java. This would allow
to write complex graphics rendering code for a lot of different
platforms and not only platforms where JavaFX already exists
and can be used. Just think of the Android canvas or, via cross-
compilation, even the HTML 5 canvas.
Just my two €ent.
Michael

Am 02.11.20 um 14:18 schrieb Bruce Johnson:

A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
allow redirecting Java2D drawing to output other than the Java2D canvas.

These work by extending java.awt.Graphics2D.  By passing the extended 
Graphics2D object into a paint method, output can be redirected to a file 
(.svg, .pdf, etc.).

The GraphicsContext class of JavaFX serves a similar function to Graphics2D of 
java.awt, but because it is a final class it cannot be extended to create 
similar functionality as found in VectorgGraphics or JFreeSVG.

This is a serious limitation (at least as far as I can tell) to JavaFX 
applications.  It would be highly desirable to be able to redirect drawing on a 
Canvas to other output formats such as vector graphics files (.svg, .pdf etc.).

I currently work around this by using composition.  I have a Java interface 
that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
implements the interface and contains an instance of GraphicsContext.  This 
class is used for drawing to the Canvas.  I’ve then created a 
SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
these can be used to draw to .svg or .pdf files.

This works, but means that all code that draws on the canvas has to be 
rewritten to take the GraphicsContextInterface rather than the normal 
GraphicsContext.

It would be much simpler if
1) GraphicsContext was not final and could be extended.
or
2) A GraphicsContextInterface existed that GraphicsContext implemented. 
 Developers could then have alternative GraphicsContext implementations that 
implemented that interface.  This would require canvas drawing code to be 
written to use the interface, but would still be very useful.

Either solution could (I think) be easily implemented in JavaFX without 
breaking existing code and add a significant advance to the toolkit.

If there are alternative solutions to the problem, that would allow exporting 
canvas drawing to vector graphics files without requiring a change to the code 
that draws to the canvas, I’d appreciate hearing them.

— Bruce

Re: GraphicsContext and export to vector format files

[Michael Paus]

Hi,
I very much like the idea in general but I think it falls too short.
Such an interface should not be tied to any existing graphics
framework. Instead it should be just pure Java. This would allow
to write complex graphics rendering code for a lot of different
platforms and not only platforms where JavaFX already exists
and can be used. Just think of the Android canvas or, via cross-
compilation, even the HTML 5 canvas.
Just my two €ent.
Michael

Am 02.11.20 um 14:18 schrieb Bruce Johnson:

A variety of packages (for example,  VectorGraphics or JFreeSVG) exist that 
allow redirecting Java2D drawing to output other than the Java2D canvas.

These work by extending java.awt.Graphics2D.  By passing the extended 
Graphics2D object into a paint method, output can be redirected to a file 
(.svg, .pdf, etc.).

The GraphicsContext class of JavaFX serves a similar function to Graphics2D of 
java.awt, but because it is a final class it cannot be extended to create 
similar functionality as found in VectorgGraphics or JFreeSVG.

This is a serious limitation (at least as far as I can tell) to JavaFX 
applications.  It would be highly desirable to be able to redirect drawing on a 
Canvas to other output formats such as vector graphics files (.svg, .pdf etc.).

I currently work around this by using composition.  I have a Java interface 
that has most methods of GraphicsContext.  Then a GraphicsContextProxy class 
implements the interface and contains an instance of GraphicsContext.  This 
class is used for drawing to the Canvas.  I’ve then created a 
SVGGraphicsContext and PDFGraphicsContext that implement the interface and 
these can be used to draw to .svg or .pdf files.

This works, but means that all code that draws on the canvas has to be 
rewritten to take the GraphicsContextInterface rather than the normal 
GraphicsContext.

It would be much simpler if
1) GraphicsContext was not final and could be extended.
or
2) A GraphicsContextInterface existed that GraphicsContext implemented. 
 Developers could then have alternative GraphicsContext implementations that 
implemented that interface.  This would require canvas drawing code to be 
written to use the interface, but would still be very useful.

Either solution could (I think) be easily implemented in JavaFX without 
breaking existing code and add a significant advance to the toolkit.

If there are alternative solutions to the problem, that would allow exporting 
canvas drawing to vector graphics files without requiring a change to the code 
that draws to the canvas, I’d appreciate hearing them.

— Bruce

Re: Can't load fxml on Macos

[Michael Paus]

With so little information nobody will be able to answer your question
and I am pretty sure that not macOS is the black sheep here.
Such questions are also better posted on Stackoverflow and not here on
the OpenJFX development mailing list.
Michael

Am 20.10.20 um 12:28 schrieb Davide Perini:

Hi all,
this code works well on both Windows and Linux running Java 15 on 
JavaFX 15.


FXMLLoader fxmlLoader =new FXMLLoader(GUIManager.class.getResource( 
fxml + Constants.FXML)); return fxmlLoader.load();



It doesn't work on Macos returning a nullpointer exception.

Any idea? Why Macos is always the black sheep?

Thanks
Davide

Re: How to set app name in macOS, gradle?

[Michael Paus]

NSMenuFX will fix, e.g., the "About" issue and will allow consistent 
internationalization

of these predefined menu items.

Am 17.09.20 um 21:55 schrieb Michael Hall:



On Sep 17, 2020, at 12:20 PM, Michael Paus <mailto:m...@jugs.org>> wrote:


You can achieve this when you bundle your application with jpackage.


With jpackage including these…
-Dapple.laf.useScreenMenuBar=true
-Dcom.apple.mrj.application.apple.menu.about.name=HalfPipe

My application name showed correctly on the top menu bar and in the dock.
Whether it was from these or just jpackage

--name -n 
          Name of the application and/or package

I don’t know. What wasn’t showing correctly was the application names 
within the application menu. Like “About LoaderLaunchStub”

These looked like they were parsed from the main class name.

app.mainclass=us.hall.hp.common.LoaderLaunchStub

After seeing this thread I found this…

-Dapple.awt.application.name=HalfPipe

Which seems to correct that.

NSMenuFX may give you additional functionality you want but with just 
the above for jpackage should get you correct looking application 
names about everywhere.

Re: How to set app name in macOS, gradle?

[Michael Paus]

You can achieve this when you bundle your application with jpackage.
For proper macOS menubar handling you should also consider to use
the library NSMenuFX (https://github.com/codecentric/NSMenuFX) because
JavaFX itself still cannot do that.
Michael

Am 17.09.20 um 19:11 schrieb Rob Nikander:

Hi,

I’m trying to set the text shown in the macOS menubar. The advice I see online 
says to use -Xdock:name, but when I try that, I still see “java” in the 
menubar. Is there a way to make it use “MyAppName”?  Some of my 
build.gradle.kts file is shown below.

Rob
 


plugins {
 application
 kotlin("jvm") version "1.4.10"
 id("org.openjfx.javafxplugin") version "0.0.9"
}

application {
 mainClass.set(“myapp.MainKt")
 applicationName = "MyAppName"
 applicationDefaultJvmArgs = listOf(
 "-Xdock:name=MyAppName"
 )
}

javafx {
 version = "15"
 modules = listOf("javafx.controls”)
}

Re: Media Player Failure When Speakers Not Present

[Michael Paus]

The URL is correct. JavaFX is still tracked by the normal JDK bug 
tracking system.


Am 14.09.20 um 22:27 schrieb omnip...@gmail.com:

I am a little confused. The url you sent appears to be for Java SE bug 
reporting and I thought that JavaFX as OpenJFX is not part of the Java SE 
distribution. If so then this may not be where I report my issue.

  


Ken

  

  


From: Nir Lisker 
Sent: September 14, 2020 4:19 PM
To: omnip...@gmail.com
Cc: openjfx-dev@openjdk.java.net Mailing 
Subject: Re: Media Player Failure When Speakers Not Present

  


PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

  


bugreport.java.com 

  


On Mon, Sep 14, 2020 at 11:03 PM mailto:omnip...@gmail.com> 
> wrote:

While I am still looking for where I can file this problem I thought I'd
bring it to the list. A program I use in my course plays a short video. Have
used it for a few years and it works fine. EXCEPT, if there is not a
connected audio out device such as speakers or headphones. The video does
not play and there is no stack trace or any other indication of a problem.
Stage opens fine but the media control does nothing and the scene appears
empty. Discovered when I used a machine that did not have speakers plugged
into it. Expected behaviour was just to see the video without sound. It is
possible that this bug has been around since the introduction of the Media /
Media Player control.



I assume the code works like "Hi M. PCaudio, what are you connected to?"
"I'm not connected to anything, M. Media Player" "That's OK M. PCAudio, I'll
just wait forever or just give up and do nothing".



Or, it can just be a crazy Xeon based Windows machine that is giving grief
to OpenJFX. Using Java 14 and OpenJFX 16-ea+1.



Ken Fogel



PS: If someone can send me the URL for OpenJFX's JIRA or equivalent, I will
submit a bug report.

Re: Blurry render of SwingNode

[Michael Paus]

Hi,
this is not a bug reporting list. Please file your bug report here
https://bugs.java.com/bugdatabase/ instead.
Best regards
Michael

Am 22.08.20 um 19:57 schrieb Thangalin:

Ahoy list,

Running OpenJDK 14.0.1 on Windows 7, adding a SwingNode to a SplitPane
causes the contents of the SwingNode to appear blurry. There's a full
write-up with screen-shots at:
https://stackoverflow.com/q/63444771/59087

Here's an SSCCE that demonstrates the problem:

import javafx.application.Application;
import javafx.embed.swing.SwingNode;
import javafx.scene.Scene;
import javafx.scene.control.SplitPane;
import javafx.scene.layout.StackPane;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;

import javax.swing.*;
import java.awt.*;

import static javafx.application.Platform.runLater;
import static javax.swing.SwingUtilities.invokeLater;

public class FlyingSourceTest extends Application {
   public static void main( String[] args ) {
 Application.launch( args );
   }

   @Override
   public void start( Stage stage ) {
 invokeLater( () -> {
   stage.setTitle( "SSCCE" );

   final var size = 120f;
   final var font = new javafx.scene.text.Font( "Arial", size );
   final var bgStyle = "-fx-background-color: white";

   // FX label, StackPane
   final var fxLabelTop = new javafx.scene.text.Text( "FX/FX" );
   fxLabelTop.setFont( font );
   final var fxStackPaneTop = new StackPane( fxLabelTop );

   // FX label, StackPane
   final var fxLabelSplit = new javafx.scene.text.Text( "FX LABEL" );
   fxLabelSplit.setFont( font );
   final var fxLabelPane = new StackPane();
   fxLabelPane.getChildren().addAll( fxLabelSplit );
   fxLabelPane.setStyle( bgStyle );

   // Swing label, StackPane
   final var swingLabel = new JLabel( "SW LABEL" );
   swingLabel.setBackground( Color.WHITE );
   swingLabel.setOpaque( true );
   swingLabel.setFont( swingLabel.getFont().deriveFont( Font.PLAIN, size ) 
);
   final var swingLabelNode = new SwingNode();
   swingLabelNode.setContent( swingLabel );
   final var swingLabelPane = new StackPane( swingLabelNode );
   swingLabelPane.setStyle( bgStyle );

   final var fxSplitPane = new SplitPane(
   fxLabelPane, swingLabelPane );
   fxSplitPane.setPrefSize( 1280, 300 );

   final var root = new VBox();
   root.getChildren().addAll( fxStackPaneTop, fxSplitPane );
   root.setStyle( bgStyle );

   runLater( () -> {
 final var scene = new Scene( root );
 stage.setScene( scene );
 stage.show();
   } );
 } );
   }
}

Closely compare the "L" from "SW LABEL" to the "L" from "FX LABEL".
You'll see that the "SW LABEL" ell has what looks like stronger
antialiasing applied.

Changing the Graphics2D rendering hints on the JLabel has no effect.
Changing the JLabel's AffineTransform to shift by 0.5px worsens the
blurriness. Moving the SwingNode out of the SplitPane renders crisply,
as expected. The font colours and background do not affect the
outcome, but are there to make consistent output, which makes
comparing easier.

This problem affects neither X11 (Linux) nor OSX, only Windows.

Been trying to fix this for several days without success.

Any ideas why embedding a SwingNode within a SplitPane causes a blurry
effect? And how can the problem be resolved?

Thank you!

Re: Tray Icon?

[Michael Paus]

My mistake. Sorry. I read the question a bit too fast :-).
Anyway, here is an example of how to use the AWT system tray
from within JavaFX. Maybe it helps: 
https://gist.github.com/jewelsea/e231e89e8d36ef4e5d8a

I just verified that this still works with Java 11+.
Otherwise I fully support the idea of getting this shortcoming fixed  in 
JavaFX itself.

Michael

Am 01.08.20 um 01:45 schrieb 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?

[Michael Paus]

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: Deadlock: JFXPanel, ContextMenu, macOS

[Michael Paus]

Hi Steven,
the right place for bug reports like this is here: 


Michael

Am 30.07.20 um 01:28 schrieb Steven Yi:

Hi All,

I'm not sure if this is the place to report this, but hopefully so. (I did
not see a way to create an account or report issues on JBS.)

I am using JavaFX embedded within a Swing application and had found
intermittent deadlocks on macOS that I wasn't sure why it was happening. I
was finally able to create a minimal working example and have published it
here:

https://github.com/kunstmusik/ContextMenuHangingTest

The switching applications seems to be a key to getting the deadlock to
happen. Testing with debugger in Netbeans, when the app freezes, I paused
the app and saw this in the Java FX Application Thread stack:

"JavaFX Application Thread"
at sun.lwawt.macosx.LWCToolkit.doAWTRunLoopImpl(LWCToolkit.java)
at sun.lwawt.macosx.LWCToolkit.doAWTRunLoop(LWCToolkit.java:913)
at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:694)
at sun.lwawt.macosx.LWCToolkit.invokeAndWait(LWCToolkit.java:639)
at sun.lwawt.macosx.CAccessibility.invokeAndWait(CAccessibility.java:94)
at sun.lwawt.macosx.CAccessibility.getFocusOwner(CAccessibility.java:548)
at com.sun.glass.ui.mac.MacWindow._setView(MacWindow.java)
at com.sun.glass.ui.Window.setView(Window.java:416)
at
com.sun.javafx.tk.quantum.WindowStage.lambda$setScene$0(WindowStage.java:287)
at com.sun.javafx.tk.quantum.WindowStage$$Lambda$359.792704517.get
at
com.sun.javafx.tk.quantum.QuantumToolkit.runWithRenderLock(QuantumToolkit.java:430)
at com.sun.javafx.tk.quantum.WindowStage.setScene(WindowStage.java:286)
at javafx.stage.Window$12.invalidated(Window.java:1085)
at
javafx.beans.property.BooleanPropertyBase.markInvalid(BooleanPropertyBase.java:110)
at
javafx.beans.property.BooleanPropertyBase.set(BooleanPropertyBase.java:145)
at javafx.stage.Window.setShowing(Window.java:1174)
at javafx.stage.Window.show(Window.java:1189)
at javafx.stage.PopupWindow.showImpl(PopupWindow.java:472)
at javafx.stage.PopupWindow.show(PopupWindow.java:417)
at javafx.scene.control.ContextMenu.doShow(ContextMenu.java:323)
at javafx.scene.control.ContextMenu.show(ContextMenu.java:265)
at
com.kunstmusik.contextmenuhangingtest.HangingTest.lambda$main$0(HangingTest.java:29)
at
com.kunstmusik.contextmenuhangingtest.HangingTest$$Lambda$191.1699780362.handle
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:86)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at com.sun.javafx.event.EventUtil.fireEventImpl(EventUtil.java:74)
at com.sun.javafx.event.EventUtil.fireEvent(EventUtil.java:49)
at javafx.event.Event.fireEvent(Event.java:198)
at javafx.scene.Node.fireEvent(Node.java:8885)
at javafx.scene.control.Button.fire(Button.java:203)
at
com.sun.javafx.scene.control.behavior.ButtonBehavior.mouseReleased(ButtonBehavior.java:206)
at
com.sun.javafx.scene.control.behavior.ButtonBehavior$$Lambda$247.642849157.handle
at com.sun.javafx.scene.control.inputmap.InputMap.handle(InputMap.java:274)
at
com.sun.javafx.scene.control.inputmap.InputMap$$Lambda$242.1652994145.handle
at
com.sun.javafx.event.CompositeEventHandler$NormalEventHandlerRecord.handleBubblingEvent(CompositeEventHandler.java:247)
at
com.sun.javafx.event.CompositeEventHandler.dispatchBubblingEvent(CompositeEventHandler.java:80)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:234)
at
com.sun.javafx.event.EventHandlerManager.dispatchBubblingEvent(EventHandlerManager.java:191)
at
com.sun.javafx.event.CompositeEventDispatcher.dispatchBubblingEvent(CompositeEventDispatcher.java:59)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:58)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at
com.sun.javafx.event.EventDispatchChainImpl.dispatchEvent(EventDispatchChainImpl.java:114)
at
com.sun.javafx.event.BasicEventDispatcher.dispatchEvent(BasicEventDispatcher.java:56)
at

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

[Michael Paus]

Am 20.07.20 um 19:40 schrieb Nir Lisker:

In addition to the other answers, you can look into GraalVM's native image:
https://www.graalvm.org/docs/reference-manual/native-image/

GraalVM native-image does not work directly with JavaFX. You would have to
use the Gluon client-maven-plugin 

to get that going but I would not recommend that as a first try because 
it is just too difficult.

You can try that step later.


On Mon, Jul 20, 2020 at 8:25 PM Davide Perini 
wrote:


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 <

perini.dav...@dpsoftware.org> 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?

[Michael Paus]

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:


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: RFR: 8196079: Remove obsolete Pisces rasterizer

[Michael Paus]

Am 18.07.20 um 17:57 schrieb Kevin Rushforth:


On 7/18/2020 8:50 AM, Michael Paus wrote:

Am 18.07.20 um 17:10 schrieb Kevin Rushforth:
Note that the SW pipeline still has a Pisces-based renderer for the 
actual rendering of primitives. This is separate

from the rasterizer and is not affected by this proposed fix.


Just out of curiosity - why is this still needed? Wouldn't it be nice 
to remove Pisces completely?


We still fall back to the SW pipeline for a few cases, such as virtual 
environments without HW graphics support (Windows Remote Desktop, 
VMWare, VirtualBox), systems with insufficient graphics HW or drivers 
(mainly on Linux, but also on some Windows servers).
I think you misunderstood my question. Of course I know that JavaFX has 
a SW pipeline which is used under certain conditions. My question was 
why this SW pipeline still uses Pisces. The Marlin renderer has replaced 
Pisces in all other areas, as far as I know. Why not also in the SW 
pipeline. In how far are the requirements of the SW pipeline different 
from the ones in AWT for example?


Michael

Re: RFR: 8196079: Remove obsolete Pisces rasterizer

[Michael Paus]

Am 18.07.20 um 17:10 schrieb Kevin Rushforth:

Note that the SW pipeline still has a Pisces-based renderer for the actual 
rendering of primitives. This is separate
from the rasterizer and is not affected by this proposed fix.


Just out of curiosity - why is this still needed? Wouldn't it be nice to 
remove Pisces completely?


Michael

Re: [Integrated] RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux

[Michael Paus]

On Mon, 1 Jun 2020 17:52:46 GMT, Michael Paus  wrote:

> It seems to be sufficient to add "intel" as an additional vendor to the list 
> in the X11GLFactory class. Tests pass and
> my own application also works with the new build.

This pull request has now been integrated.

Changeset: 97499820
Author:Michael Paus 
Committer: Kevin Rushforth 
URL:   https://git.openjdk.java.net/jfx/commit/97499820
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod

8246204: No 3D support for newer Intel graphics drivers on Linux

Reviewed-by: kcr

-

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

Re: [Rev 01] RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux

[Michael Paus]

> It seems to be sufficient to add "intel" as an additional vendor to the list 
> in the X11GLFactory class. Tests pass and
> my own application also works with the new build.

Michael Paus has updated the pull request incrementally with one additional 
commit since the last revision:

  Remove duplicate GLGPUInfo according to review comment
  
  My original intention was to keep two entries in order to make it clearer 
that there are currently two distinct vendor
  strings for Intel floating around. But having just one entry which covers 
both cases is ok for me too.

-

Changes:
  - all: https://git.openjdk.java.net/jfx/pull/243/files
  - new: https://git.openjdk.java.net/jfx/pull/243/files/759af32c..4142adb3

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

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

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

Re: RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux

[Michael Paus]

On Mon, 1 Jun 2020 17:52:46 GMT, Michael Paus  wrote:

> It seems to be sufficient to add "intel" as an additional vendor to the list 
> in the X11GLFactory class. Tests pass and
> my own application also works with the new build.

Here is the crosslink to the JBS issue: 
https://bugs.openjdk.java.net/browse/JDK-8246204

-

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

RFR: 8246204: No 3D support for newer Intel graphics drivers on Linux

[Michael Paus]

It seems to be sufficient to add "intel" as an additional vendor to the list in 
the X11GLFactory class. Tests pass and
my own application also works with the new build.

-

Commit messages:
 - Fix JDK-8246204

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

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

Re: [Rev 02] RFR: 8245053: Keyboard doesn't show when TextInputControl has focus

[Michael Paus]

On Fri, 29 May 2020 12:48:29 GMT, Johan Vos  wrote:

>> Abhinay Agarwal has updated the pull request incrementally with one 
>> additional commit since the last revision:
>> 
>>   Skin implementation must maintain the contract of dispose
>
> Looks good.
> A test strategy for Android is a good idea for a follow-up issue.

Have you considered the case where a TextField is focused by default when its 
view is shown? As soon as the view is
shown the keybord will pop up, even if the user does not plan to edit anything. 
I just experienced this when I
exchanged the Label in the HelloGluon example against a TextField. A lot of 
strange things then happen. The keyboard
pops up, it hides the Gluon nag screen, if you close the keyboard and the nag 
screen you still see these edit markers
and all this just because this text field was focused by default. To my opinion 
the keyboard and the edit markers
should only be shown when the user actually clicks into the text field and thus 
indicates that he really wants to edit
something. I also noticed that after the keyboard was shown I could not 
normally close the application anymore. (This
was on Android with a Galaxy Tab 4)

-

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

Re: HID multitouch display support in JavaFX

[Michael Paus]

Having proper and consistent Multitouch support on all platforms is 
certainly
an interesting goal, especially if your development is targeting a 
mobile platform. If one

could test the input behavior already on the desktop, this would be an
enormous time saver because the turn-around times 
(edit-compile-build-deploy-debug-curse)
for mobile are currently still extremely high and thus not very 
development-friendly.

I learned from your mail that the situation on Windows seems to be better
than on macOS, which is my current development environment. That gives
me an idea :-)

Am 13.05.20 um 10:15 schrieb jfx user2:

Nobody is biting... so is anyone else out there interested in using HID
touchscreens with JavaFX on OSX (or any other plaform) without using a
third party driver?

On Fri, May 8, 2020 at 4:18 AM jfx user2  wrote:


Multitouch display support JavaFX on Windows, iOS, and Android seems
straightforward.  If the OS recognizes the display as multitouch, then the
chances are that JavaFX will also work with it since it relies on the
native multitouch support of the OS.

When it comes to Linux and OSX, it's not always as easy.  Linux sometimes
requires device mapping.  I'm not sure if it works at all in OSX unless you
have specific drivers for the display.

All of the platforms seem to support HID so maybe JavaFX could have direct
support for HID devices (optionally) if they are present instead of just
the current method.  It may also improve performance in cases where the OS
is just piping HID events through their own API's to support multitouch.
Why not just go straight to the HID source and bypass that conduit.

This would vastly improve multitouch app development on OSX.  It would be
possible to connect a HID display and use it for testing apps that are
destined for platforms that formally support multitouch.

Is there any work being done in this area?  Is there a bigger picture
(e.g. better multi-display and connect/disconnect support in JavaFX)?

... coming from a frustrated OSX user with lots of HID displays and no
easy JavaFX support.

https://www.usb.org/hid

Re: com.sun.javafx vs javafx (with example/request)

[Michael Paus]

I think I know quite a bit about JavaFX graphics and I do not generally 
agree with your statements.
Especially the statement that the Canvas is so much superior is a myth 
from the old days of Java 8
where there were a few performance bugs in the scene graph handling. But 
that's a long time ago.
(I even gave a workshop on this at the JavaLand conference some time 
ago.) Maybe you could present
a few more details about your use-case and not so much about the 
technique that you think is the
best fit for it. Maybe even some demo code somewhere. I am always 
interested in a discussion about
graphics as long as it is supported by facts. Neither the scene graph 
nor the canvas is a silver bullet.

It always depends on your use-case.
Michael

Am 09.05.20 um 00:18 schrieb jfx user2:
From the JavaDoc "Canvas is an image that can be drawn on using a set 
of graphics commands provided by a GraphicsContext."  This a bit of a 
misnomer.  While canvas can be used to draw in image (actually 
GraphicsContext not canvas itself), the image based methods of 
GraphicsContext are far outweighed by the "vector" or path based 
methods.  The GraphicsContext gives you the ability to freely create 
dynamic graphics without the constraints of the Scene Graph.  It can 
be highly performant and scalable if done properly.  The Scene Graph 
will not perform like the GraphicsContext.  If you haven't worked with 
highly dynamic graphics, you might not have encountered any issues.  
The Scene Graph works ok up to a certain number of objects and it is 
not good at adding and removing objects often.  GraphicsContext does 
not have the same restrictions.  It can involve more work but the end 
result will scale far beyond what you can do in a Scene Graph... I 
think this is already widely accepted.


The proposed method on the GraphicsContext simply returns what is 
already there.  It would convert the already stored Path2D to a Path.  
Why reinvent what is already present and only private? This in turn 
CAN be used in the Scene Graph but it can also be used as a container 
to draw back onto the GraphicsContext.  You see,  a Path that is 
calculated once and then used repeatedly to draw in the 
GraphicsContext (possibly even transformed) is better than 
sub-optimally calculating that Path on every pass through the 
GraphicsContext or storing it as an image or Shape (those were some of 
my workarounds).


Anyway, I'm requesting that a private API be used to create a new 
public method.  This is really no different than existing public 
methods that use private APIs.  I'm not asking to expose private APIs 
(not in this request :o).  There isn't even much code.  It's reusing 
what's already there.


Ask Gerrit Grunwald about his experience with the Scene Graph vs 
Canvas/GraphicsContext.



On Fri, May 8, 2020 at 4:27 PM Michael Paus <mailto:m...@jugs.org>> wrote:


Hi,
I have to say that your requirements sound a little bit strange to
me,
but maybe you can make it clearer what your real use-case behind
them is.
What I do not understand is why you are using the canvas at all.
Conceptually the canvas is for direct mode rendering into an
image. The
fact that
this is handled a little bit different internally is an
implementation
detail, you should not rely on. Why don't you use the scene graph
which
seems
to provide many of the aspects that you need? I admit that there
are a
few hidden gems internally that I would also like to be made public
(e.g. the flattening path iterator) but I definitely see these things
more in the scene graph context but not for Canvas.
Just my two €ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:
> No... given a Shape, create a Path that represents the outline
of that shape.  If I had a Path I wouldn’t be requesting the new
methods.
>
> One of the workarounds for getting a Path from a GraphicsContext
is to keep track of it as I’m drawing... however, this is overhead
in the gc call that can become very expensive when you have a lot
of gcs or if your gc is doing a lot of work.  The path is already
there in Path2D along with a method to convert it to a public
Path.  There’s no need for an expensive custom workaround.  All
that’s required is a method on the GraphicsContext that returns a
Path.  The same is true for getting a Path from a Shape.
>
> Please note that this behavior is desirable for highly optimized
use of GraphicsContext and Shapes where you need “outlines” of
things in vector format.  The private api is unnecessarily hiding
this information.
>
>> On May 8, 2020, at 3:38 PM, Philip Race mailto:philip.r...@oracle.com>> wrote:
>>
>> The current path is defined by the application - you - and yet
you don't know what it is  ?
>> You do say
&g

Re: com.sun.javafx vs javafx (with example/request)

[Michael Paus]

Hi,
I have to say that your requirements sound a little bit strange to me, 
but maybe you can make it clearer what your real use-case behind them is.
What I do not understand is why you are using the canvas at all. 
Conceptually the canvas is for direct mode rendering into an image. The 
fact that
this is handled a little bit different internally is an implementation 
detail, you should not rely on. Why don't you use the scene graph which 
seems
to provide many of the aspects that you need? I admit that there are a 
few hidden gems internally that I would also like to be made public 
(e.g. the flattening path iterator) but I definitely see these things 
more in the scene graph context but not for Canvas.

Just my two €ent.
Michael

Am 08.05.20 um 22:08 schrieb jfx user2:

No... given a Shape, create a Path that represents the outline of that shape.  
If I had a Path I wouldn’t be requesting the new methods.

One of the workarounds for getting a Path from a GraphicsContext is to keep 
track of it as I’m drawing... however, this is overhead in the gc call that can 
become very expensive when you have a lot of gcs or if your gc is doing a lot 
of work.  The path is already there in Path2D along with a method to convert it 
to a public Path.  There’s no need for an expensive custom workaround.  All 
that’s required is a method on the GraphicsContext that returns a Path.  The 
same is true for getting a Path from a Shape.

Please note that this behavior is desirable for highly optimized use of 
GraphicsContext and Shapes where you need “outlines” of things in vector 
format.  The private api is unnecessarily hiding this information.


On May 8, 2020, at 3:38 PM, Philip Race  wrote:

The current path is defined by the application - you - and yet you don't know 
what it is  ?
You do say

I have other workarounds where I have to maintain a path as I’m drawing in the 
canvas

Why can't you do that ? No internal API digging.

-phil


On 5/8/20, 12:02 PM, jfx user2 wrote:
Ok, then please consider the GraphicsContext request that I’ve made.  It simply 
enables you to get the Path from the context without exposing com classes at 
all.  I have other workarounds where I have to maintain a path as I’m drawing 
in the canvas or I have to do hit testing on a non vector image to determine 
the path but these are way more expensive than simply creating a Path object 
from the Path2D that is already in the GraphicContext.  That path can be used 
in drag and drop scenarios, fast secondary rendering under heavy gc use, edge 
tracing, and the list goes on.

The same is true for the Shape class.  I’d like to request that the following 
be added to Shape:
public Path getPath() {
 return Shape.createFromGeomShape(getTransformedArea());
}

That’s it.  The underlying methods are there but the public api doesn’t expose 
them.  This gives you a vector outline of the Shape as Path.l on demand, not 
stored.

There are expensive workarounds for performing these tasks and I spent a long 
time trying... until I discovers the private apis already had the capability 
but simply did. It expose it.

I’d these are not supported, I’ll have to stick with reflection,  bytebuddy, or 
forking - non of which will be easily maintained or portable.

Ps I will post additional concerns over time.  The next one likely has to do 
with the mismatch between javafx canvas (gc) and other canvases such as svg, 
html2.  I think there is private api that would help in this case.


On May 8, 2020, at 2:41 PM, Kevin Rushforth  wrote:

Since Canvas is an immediate mode graphics API, I presume you are interested 
in the most recent drawing primitive? (we don't keep the composite shape for 
all drawing primitives -- that would be both too expensive and not really 
appropriate). How would you expect current rendering attributes (e.g., 
transforms) to affect the results? These are all questions that need to be 
addressed.

As for the bigger picture, we intentionally have a separate render graph with 
"peers" for each node, although some of the duplication of classes is 
historical (we used to have a looser decoupling before Prism became the only backend). 
Unless there is a compelling need, we are unlikely to consider changing this in the 
general case, but perhaps could look at specific cases if it made sense. This is a 
separate issue, though, from public API and the two shouldn't be conflated.

Btw, JavaFX has been fully open-sourced since 2013, although the design of 
Prism predates that.

-- Kevin



On 5/8/2020 10:43 AM, jfx user2 wrote:
Kevin, go easy please :0).  There is a need.

Access to the outline of the path in the canvas is great for edge following, 
node attachment points, animating around the non-rectangular border of what’s 
actually displayed, etc.

The other request that I haven’t posted yet is to do the same for Shape.   I’ve 
tested both of these enhancements and it works as desired.  I’ll post the 
second request soon.

But back to the 

Re: [Rev 03] RFR: 8217472: Add attenuation for PointLight

[Michael Paus]

Am 25.04.20 um 19:09 schrieb Kevin Rushforth:

On Fri, 24 Apr 2020 05:06:56 GMT, Phil Race  wrote:


Here is a slightly modified test program. It fixes a compilation error in the 
previous, and also adds a system property
to set the number of quads:
It creates 200 quads by default. If you need to increase this or decrease it to 
get something in the ~ 10 fps range you
can do that with `-DnumQuads=`.
[pointlighttest.zip](https://github.com/openjdk/jfx/files/4526179/pointlighttest.zip)

@kevinrushforth
Member
kevinrushforth commented Apr 18, 2020

I think most of those are good suggestions going forward. As for the 
performance drop, the only place we've seen it so
far is on graphics accelerators that are a few years old by now.
So 50% drop on a 2015 macbook pro is OK ? Do we have numbers on recent macbook 
pros ?

If this were an even remotely representative use case, then no, the performance 
hit would not be OK. The test was
designed as an artificial "worst-case" stress test: a single mesh with a large 
number of very large (window-sized)
quads stacked on top of each other. Any real-world use case won't do this.

We should make sure that we aren't seeing any significant performance drop when 
rendering spheres (at a couple
different tessellation levels) or boxes.

-

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


Will there also be any performance drop in case you just use the default 
parameters for the lighting?
The default, which corresponds to the current lighting, should not need 
any additional computations

and thus no performance drop.

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

Hi Bruno
I actually like the fact that JavaFX has been split up into some smaller 
parts.
E.g., javafx.web is the biggest moster in this context and if you do not 
really
need it, it is nice that you leave it out. Also media, swing and fxml 
are not

always needed and so you can leave them out. I even have cases where I only
allow javafx.base because that is all you need to write your view-models and
it is good that you can explicitly separate that from all the graphics 
and control

stuff. So I have absolutely no problem with that kind of modularization.
Michael

Am 20.04.20 um 20:18 schrieb Bruno Borges:

I do wonder why isn't JavaFX in a single module, like Swing?

For Java developers to build Swing apps, all they need is a "requires 
java.desktop".


But for JavaFX, there are multiple modules.

---
*Bruno Borges*
brunoborges.io <http://brunoborges.io>


On Mon, Apr 20, 2020 at 10:36 AM Michael Paus <mailto:m...@jugs.org>> wrote:


Oh I see. You  are obviously not familiar with the fact that the
JDK has
a built-in test
which checks whether the JavaFX graphics module is on the module path
when you
try to launch an application main class which is derived from the
JavaFX
Application class.
If you try this and the graphics module is not on the module path the
launch will fail
with an error message. That's the only reason why JavaFX programs
cannot
be launched
completely on the classpath and that's where all the trouble
starts. If
you circumvent this
test with the trick, I have mentioned before, everything becomes nice
and easy.

So for me there are only two questions.
1. Is there any proof of a technical reason why JavaFX could not run
correctly on the classpath?
2. If there is no such reason, then why do we torture all the newbies
with the "intricacies" of the
module system instead of just removing this barrier?

As I said before, I have not found any such problem in all the time
since JavaFX was separated
from the JDK, so this test seems to be quite artificial to me but of
course I may be wrong. That's
why I asked here.

Am 20.04.20 um 17:25 schrieb Ty Young:
>
> I'm a bit confused here. if you don't want JPMS then you should be
> able to run everything on the classpath like normal. Netbeans at
least
> doesn't force modules wtih Maven. Or is reflection disabled on
> classpath as of Java 9 too unless you have a module-info?
>
>
>>
>> Michael
>>
>> Am 18.04.20 um 12:58 schrieb Ty Young:
>>>
>>> On 4/18/20 5:01 AM, Michael Paus wrote:
>>>> Getting started with JavaFX is made overly complicated by the
fact
>>>> that the use of the
>>>> module system is enforced by some code in the JDK. Especially
for
>>>> beginners, who just
>>>> want to get some small program running, this is almost always
a big
>>>> source of frustration.
>>>> It is not very good marketing for JavaFX to make these initial
>>>> steps such a pain. If you
>>>> need some evidence for this statement, then just follow
JavaFX on
>>>> Stackoverflow or similar
>>>> sites (and also this mailing list). Almost every day you can
read
>>>> frustrated posts from
>>>> helpless people who would just like to get some JavaFX project
>>>> running but are failing
>>>> because they get lost in the module system jungle.
>>>
>>>
>>> Speaking as a long time JavaFX user(literally since Java 8), I
have
>>> mostly disagree that the JPMS is hurting JavaFX.
>>>
>>>
>>> That said, I don't think the frustration is misplaced. What
you say
>>> is true(Netbeans mailing list is fill of JavaFX issues) and
the end
>>> user is *NOT* to be blamed here.
>>>
>>>
>>> Rather, I think what's to blame is poor documentation, JavaFX
>>> requiring absurd runtime module VM arguments, and  poor/buggy IDE
>>> support.
>>>
>>>
>>> Starting with documentation, JavaFX uses reflection for things
like
>>> TableView(everyone's favorite) and CSS style sheets. While
this may
>>> be obvious for people who are more experienced, those who are not
>>> may be very confused when they get an onslaught of error messages
>>> regarding reflection. Better documentation on what requires
>>> reflection, why, and how to enable it would be useful.
>>>
>>>
&g

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

Oh I see. You  are obviously not familiar with the fact that the JDK has 
a built-in test
which checks whether the JavaFX graphics module is on the module path 
when you
try to launch an application main class which is derived from the JavaFX 
Application class.
If you try this and the graphics module is not on the module path the 
launch will fail
with an error message. That's the only reason why JavaFX programs cannot 
be launched
completely on the classpath and that's where all the trouble starts. If 
you circumvent this
test with the trick, I have mentioned before, everything becomes nice 
and easy.


So for me there are only two questions.
1. Is there any proof of a technical reason why JavaFX could not run 
correctly on the classpath?
2. If there is no such reason, then why do we torture all the newbies 
with the "intricacies" of the

module system instead of just removing this barrier?

As I said before, I have not found any such problem in all the time 
since JavaFX was separated
from the JDK, so this test seems to be quite artificial to me but of 
course I may be wrong. That's

why I asked here.

Am 20.04.20 um 17:25 schrieb Ty Young:


I'm a bit confused here. if you don't want JPMS then you should be 
able to run everything on the classpath like normal. Netbeans at least 
doesn't force modules wtih Maven. Or is reflection disabled on 
classpath as of Java 9 too unless you have a module-info?





Michael

Am 18.04.20 um 12:58 schrieb Ty Young:


On 4/18/20 5:01 AM, Michael Paus wrote:
Getting started with JavaFX is made overly complicated by the fact 
that the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial 
steps such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project 
running but are failing

because they get lost in the module system jungle.



Speaking as a long time JavaFX user(literally since Java 8), I have 
mostly disagree that the JPMS is hurting JavaFX.



That said, I don't think the frustration is misplaced. What you say 
is true(Netbeans mailing list is fill of JavaFX issues) and the end 
user is *NOT* to be blamed here.



Rather, I think what's to blame is poor documentation, JavaFX 
requiring absurd runtime module VM arguments, and  poor/buggy IDE 
support.



Starting with documentation, JavaFX uses reflection for things like 
TableView(everyone's favorite) and CSS style sheets. While this may 
be obvious for people who are more experienced, those who are not 
may be very confused when they get an onslaught of error messages 
regarding reflection. Better documentation on what requires 
reflection, why, and how to enable it would be useful.



Likewise, the notice about having to include javafx.graphics to the 
runtime module arguments here:



https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't 
know what was changed in JavaFX 14 that now suddenly requires a 
runtime VM argument, but it's a PITA and BS. End users are going to 
struggle with this, and it prevents JavaFX runtime from being purely 
managed by Maven. No other JavaFX version requires this, so it's 
mind boggling that all of a sudden JavaFX needs this.



Poor/buggy IDE support is really the big one here. I don't know 
about other IDEs but Netbeans DOES NOT provide a project template 
for creating a JavaFX application with setup dependencies. Netbeans, 
when setup with a Maven project, allows you to select an entire 
project(pom) rather than the individual dependencies(jar) which 
doesn't work. What you search for also matters: if you search for 
"JavaFX" you will get the wrong search results. You need to search 
for "openjfx" which can be confusing.



Anyway, yeah, it's a PITA. There is also an issue with Ant based 
projects and Netbeans because JavaFX puts its src.zip in a folder 
that is supposed to only include the runtime library that has 
existed for years(literally a 1 line fix too). No one really uses 
Ant anymore so it's probably not a big deal now but yeah, getting 
JavaFX working hasn't been "include and done" when it could 
potentially be that way.

Re: Ad GraalVM and JavaFX (Re: Remove JavaFX JPMS enforcement

[Michael Paus]

The Android/iOS work is based on GraalVMs Native Image which has some 
limitations.
These can be found here: 
https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
I stumbled over the problem with Method Handles when I tried to 
integrate some third-party
software into it. (E.g. Log4J and NSMenuFX)(I had to abandon Log4J and 
fixed the problems in NSMenuFX.)


Am 20.04.20 um 15:26 schrieb Rony G. Flatscher:

On 20.04.2020 15:06, Michael Paus wrote:

This is deviating quite a bit from the original issue of this thread, isn't it?

As a side note: MethodHandles are not supported by GraalVM native image
and so this would probably collide with the attempts to get JavaFX running
on Android/iOS.

Would you have some link where there would be a technical overview about how 
Java and JavaFX support
gets currently realized under Android/iOS? Also, how is reflection supposed to 
be carried out on
that platform, ie. is java.lang.reflect available?

---rony

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

This is deviating quite a bit from the original issue of this thread, 
isn't it?


As a side note: MethodHandles are not supported by GraalVM native image
and so this would probably collide with the attempts to get JavaFX running
on Android/iOS.

Am 20.04.20 um 11:28 schrieb Mike Hearn:

With respect to reflection, it seems like the module system really wants
you to use Lookup capabilities rather than "open" modules to reflection.
That is, JFX could be changed to use

var objects = FXMLLoader.load(MethodHandles.lookup(), new URL(""));

The semantics of a Lookup are that it grants whoever holds the object the
same access rights as whoever created it. Thus if an object creates a
Lookup and gives it to a framework, that framework can access anything the
object could itself access.

The lookup object would then be used to do reflection rather than the
classical reflection API. With this change the API would guide you to a
form that always works, regardless of module configuration.

Due to its nature as a GUI toolkit JFX often needs to reflect over user
code. It may be worth considering a deeper upgrade in which a Lookup object
is provided during application startup, and passed in to the framework e.g.
the Application class. Lookup objects can be 'teleported' so JFX components
that wish to work with user GUI code generically can then fetch a Lookup
from a central place. However, this wouldn't allow overriding of access
control (i.e. FXMLLoader that takes such a lookup and teleports it to the
right class for access, wouldn't be able to access private fields, because
the original place where the lookup was created also couldn't).

Re: Windows Installation Instructions, All DLL Files Missing

[Michael Paus]

Yes, that's what I use in my example together with jlink and jpackage.

Am 20.04.20 um 03:55 schrieb Eric Bresie:

Would jdeps help to see what dependencies are needed?

Eric Bresie
ebre...@gmail.com

On April 18, 2020 at 1:44:43 PM CDT, Michael Paus  wrote:
Hi Christopher,
I do not know what your specific problem is but maybe you just have to
shift your goals a little bit.
Continuing like you did in the Java 8 days is not a good idea for
various reasons. The current trend
for distributing desktop software with Java is to build a platform
specific installer. The tools for that
are all there. Just give it a try. Together with Dirk Lemmermann I have
set up a working example
and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac
and Windows (should also work
on Linux but I haven't tested it.)
<https://github.com/dlemmermann/JPackageScriptFX>
The nice thing about this approach is that your customer does not have
to have anything installed on his
own machine. He can just install your software like he would install any
other piece of software.
Michael

Am 18.04.20 um 20:18 schrieb Christopher Miles:

Yep, that's where I downloaded it from.


PS C:\Users\cmiles\source\repos\xmltool> java --version
openjdk 14.0.1 2020-04-14
OpenJDK Runtime Environment (build 14.0.1+7)
OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and
compare it to the "bin" directory that comes with OpenJDK there are
things in the JavaFX distribution that aren't present in the OpenJDK
distribution. These three caught my attention:

+ prism_common.dll
+ prism_d3d.dll
+ prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I
try to launch my application.

I took a look at "JDK-8207015" and I don't think that is my problem,
yet. It could be that if the "prism_xxx.dll" files were present, I
might run into this issue.

I changed my `jlink` command to point at the "mods" as this seems like
the correct way to do this. Still, the app refuses to launch with the
same error message.


Graphics Device initialization failed for : d3d, sw
Error initializing QuantumRenderer: no suitable pipeline found
java.lang.RuntimeException: java.lang.RuntimeException: Error

initializing QuantumRenderer: no suitable pipeline found

I would very much like to avoid adding switches to a `java` invocation
in order to run the application. In your example, I would need to have
customer installed the JavaFX JDK to a specific location in order for
that to work. I'd also need to have some kind of wrapper to handle
other operating systems, like Linux or OS X. My goal is to distribute
one package with custom launching scripts (i.e. one for batch,
Powershell, and Linux/OS X shell) as I did under Java 8. This makes me
think that using `jlink` with the mods is the way to go, as long as I
can figure out why that is not working.

Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:

 From where are you getting your OpenJDK build?
https://jdk.java.net/14 ? Somewhere else?

-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:

Yeah, I've tried it with both. The instructions on the JavaFX page
tell you to add the "lib" directory to the `javac` path and the
"mods" to the `jlink` path. I figured, since nothing is working, why
not try them the other way around? In all cases the results are the
same.

I'm using OpenJDK, wouldn't that project have the same issue
distributing these DLL files? I would bet they would, since they are
also an open source project. I can run Swing projects, however,
without these DLL files.

I can give the Oracle JDK a try. I had been shying away from it
since OpenJDK is getting to be so popular. If that works, I will let
the list know.

As an aside, the JavaFX home page recommends using OpenJDK right now:

https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:

Where are you getting JDK 14.0.1 from? Does it include the
Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There
are 45 of them (40 of them are of the form api-ms-win-*.dll). The
JavaFX 14.0.1 sdk includes them, but the jmods do not. See
JDK-8207015 [1] for why not. If the JDK has them, then there should
be no problem running a jlinked app.

One possible problem is that your jlink line is wrong. You should
not point to the SDK at all when running jlink. Use the jmods with
jlink (don't use the sdk). Use the sdk with javac and java
--module-path (don't use the jmods at all).

Btw, even if you are running a JDK that for some reason doesn't
have the Microsoft DLLs, you should still be able to run using the
SDK (directly, not via jlink, which requires the jmods) as follows:

java --module-path "C:\Program Files\Java\javafx-sdk-14\lib"
--add-modules
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,jav

Re: Windows Installation Instructions, All DLL Files Missing

[Michael Paus]

Hi Christopher,
I do not know what your specific problem is but maybe you just have to 
shift your goals a little bit.
Continuing like you did in the Java 8 days is not a good idea for 
various reasons. The current trend
for distributing desktop software with Java is to build a platform 
specific installer. The tools for that
are all there. Just give it a try. Together with Dirk Lemmermann I have 
set up a working example
and tutorial on GitHub. It uses the latest Java/JavaFX and works on Mac 
and Windows (should also work
on Linux but I haven't tested it.) 

The nice thing about this approach is that your customer does not have 
to have anything installed on his
own machine. He can just install your software like he would install any 
other piece of software.

Michael

Am 18.04.20 um 20:18 schrieb Christopher Miles:

Yep, that's where I downloaded it from.

> PS C:\Users\cmiles\source\repos\xmltool> java --version
> openjdk 14.0.1 2020-04-14
> OpenJDK Runtime Environment (build 14.0.1+7)
> OpenJDK 64-Bit Server VM (build 14.0.1+7, mixed mode, sharing)

When I look at the "bin" directory that came with the JavaFX SDK and 
compare it to the "bin" directory that comes with OpenJDK there are 
things in the JavaFX distribution that aren't present in the OpenJDK 
distribution. These three caught my attention:


  + prism_common.dll
  + prism_d3d.dll
  + prism_sw.dll

I suspect missing these DLL's is what is causing the exception when I 
try to launch my application.


I took a look at "JDK-8207015" and I don't think that is my problem, 
yet. It could be that if the "prism_xxx.dll" files were present, I 
might run into this issue.


I changed my `jlink` command to point at the "mods" as this seems like 
the correct way to do this. Still, the app refuses to launch with the 
same error message.


> Graphics Device initialization failed for :  d3d, sw
> Error initializing QuantumRenderer: no suitable pipeline found
> java.lang.RuntimeException: java.lang.RuntimeException: Error 
initializing QuantumRenderer: no suitable pipeline found


I would very much like to avoid adding switches to a `java` invocation 
in order to run the application. In your example, I would need to have 
customer installed the JavaFX JDK to a specific location in order for 
that to work. I'd also need to have some kind of wrapper to handle 
other operating systems, like Linux or OS X. My goal is to distribute 
one package with custom launching scripts (i.e. one for batch, 
Powershell, and Linux/OS X shell) as I did under Java 8. This makes me 
think that using `jlink` with the mods is the way to go, as long as I 
can figure out why that is not working.


Thank you for your help with this. :-)

Kevin Rushforth wrote on 4/17/2020 17:34:
 From where are you getting your OpenJDK build? 
https://jdk.java.net/14 ? Somewhere else?


-- Kevin


On 4/17/2020 2:16 PM, Christopher Miles wrote:
Yeah, I've tried it with both. The instructions on the JavaFX page 
tell you to add the "lib" directory to the `javac` path and the 
"mods" to the `jlink` path. I figured, since nothing is working, why 
not try them the other way around? In all cases the results are the 
same.


I'm using OpenJDK, wouldn't that project have the same issue 
distributing these DLL files? I would bet they would, since they are 
also an open source project. I can run Swing projects, however, 
without these DLL files.


I can give the Oracle JDK a try. I had been shying away from it 
since OpenJDK is getting to be so popular. If that works, I will let 
the list know.


As an aside, the JavaFX home page recommends using OpenJDK right now:

  https://openjfx.io/openjfx-docs/#install-java

Thank you!

Kevin Rushforth wrote on 4/17/2020 16:51:
Where are you getting JDK 14.0.1 from? Does it include the 
Microsoft VS2017 DLLs and Windows SDK DLLs in jdk-14.0.1/bin? There 
are 45 of them (40 of them are of the form api-ms-win-*.dll). The 
JavaFX 14.0.1 sdk includes them, but the jmods do not. See 
JDK-8207015 [1] for why not. If the JDK has them, then there should 
be no problem running a jlinked app.


One possible problem is that your jlink line is wrong. You should 
not point to the SDK at all when running jlink. Use the jmods with 
jlink (don't use the sdk). Use the sdk with javac and java 
--module-path (don't use the jmods at all).


Btw, even if you are running a JDK that for some reason doesn't 
have the Microsoft DLLs, you should still be able to run using the 
SDK (directly, not via jlink, which requires the jmods) as follows:


java --module-path "C:\Program Files\Java\javafx-sdk-14\lib" 
--add-modules 
javafx.base,javafx.controls,javafx.fxml,javafx.graphics,javafx.media,javafx.swing,javafx.web 
MyApplication


If this doesn't work without you putting javafx-sdk-14/bin in your 
PATH then something else is wrong.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8207015

On 4/17/2020 1:18 PM, Christopher Miles wrote:
I have 

Re: Remove JavaFX JPMS enforcement

[Michael Paus]

Hi,
I would just like to add that many of the problems you have cited would 
just vanish if the JPMS
enforcement would be removed from the JDK. There would be no "JavaFX 
requiring absurd
runtime module VM arguments" anymore and the IDE integration would just 
be straight forward.
JavaFX would become just one more dependency whithout the need for any 
special treatment.


I did, however, not say that JavaFX should be de-modularized. For an 
expert user who wants

to use the JPMS nothing would change at all.

Michael

Am 18.04.20 um 12:58 schrieb Ty Young:


On 4/18/20 5:01 AM, Michael Paus wrote:
Getting started with JavaFX is made overly complicated by the fact 
that the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial steps 
such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project 
running but are failing

because they get lost in the module system jungle.



Speaking as a long time JavaFX user(literally since Java 8), I have 
mostly disagree that the JPMS is hurting JavaFX.



That said, I don't think the frustration is misplaced. What you say is 
true(Netbeans mailing list is fill of JavaFX issues) and the end user 
is *NOT* to be blamed here.



Rather, I think what's to blame is poor documentation, JavaFX 
requiring absurd runtime module VM arguments, and  poor/buggy IDE 
support.



Starting with documentation, JavaFX uses reflection for things like 
TableView(everyone's favorite) and CSS style sheets. While this may be 
obvious for people who are more experienced, those who are not may be 
very confused when they get an onslaught of error messages regarding 
reflection. Better documentation on what requires reflection, why, and 
how to enable it would be useful.



Likewise, the notice about having to include javafx.graphics to the 
runtime module arguments here:



https://openjfx.io/openjfx-docs/#IDE-NetBeans


Apply to Maven as well, but it's under Ant for some reason. I don't 
know what was changed in JavaFX 14 that now suddenly requires a 
runtime VM argument, but it's a PITA and BS. End users are going to 
struggle with this, and it prevents JavaFX runtime from being purely 
managed by Maven. No other JavaFX version requires this, so it's mind 
boggling that all of a sudden JavaFX needs this.



Poor/buggy IDE support is really the big one here. I don't know about 
other IDEs but Netbeans DOES NOT provide a project template for 
creating a JavaFX application with setup dependencies. Netbeans, when 
setup with a Maven project, allows you to select an entire 
project(pom) rather than the individual dependencies(jar) which 
doesn't work. What you search for also matters: if you search for 
"JavaFX" you will get the wrong search results. You need to search for 
"openjfx" which can be confusing.



Anyway, yeah, it's a PITA. There is also an issue with Ant based 
projects and Netbeans because JavaFX puts its src.zip in a folder that 
is supposed to only include the runtime library that has existed for 
years(literally a 1 line fix too). No one really uses Ant anymore so 
it's probably not a big deal now but yeah, getting JavaFX working 
hasn't been "include and done" when it could potentially be that way.

Remove JavaFX JPMS enforcement

[Michael Paus]

Getting started with JavaFX is made overly complicated by the fact that 
the use of the
module system is enforced by some code in the JDK. Especially for 
beginners, who just
want to get some small program running, this is almost always a big 
source of frustration.
It is not very good marketing for JavaFX to make these initial steps 
such a pain. If you
need some evidence for this statement, then just follow JavaFX on 
Stackoverflow or similar
sites (and also this mailing list). Almost every day you can read 
frustrated posts from
helpless people who would just like to get some JavaFX project running 
but are failing

because they get lost in the module system jungle.

In order to make JavaFX more easily accessible, especially for 
beginners, I'd like to start
a discussion here about the possibility to unconditionally remove the 
JavaFX JPMS
enforcement. IMHO this enforcement is simply not necessary and is just 
the root for a lot
of frustration with JavaFX. It should just be possible to put all the 
JavaFX jars on the
classpath (instead of the module path) like you would do with any other 
external dependency

in a non-modular setup.

With a not very intuitive hack you can circumvent this problem already now.
Just add a line like this to the file which contains your main class 
extending

Application (MyApp).

class MyAppLauncher {public static void main(String[] args) 
{MyApp.main(args);}}


Because of this launcher it is now possible to put all dependencies and 
all JavaFX jars
on the classpath and to completely forget the module system with all its 
intricacies and pitfalls.
But why should people be forced to use such dirty tricks? The better 
alternative would be to just

lift the current constraint.

I am using this trick for a long time now, even on bigger projects, and 
I have never ever
experienced any problem resulting from this. Even in theory I don't know 
anything that
could prevent a formally correct module jar to also work on the 
classpath (which is of
course not true the other way round). Therefore I say that this 
constraint is just not

necessary and only does a lot of damage to JavaFXs reputation.

I'd now like to have some feedback of the community about this.

Michael

Re: Shared buffer in PixelBuffer

[Michael Paus]

Hi,
it is nice to hear that you could make some good use of this work.
Michael
(mipastgt)


Am 07.04.20 um 02:36 schrieb hohonu...@icloud.com:

Hi All,

I just wanted to send a "thank you!" to all the JavaFX devs for your work on 
JavaFX and most especially, adding shared memory to JavaFX’s PixelBuffer. 
(https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-June/023347.html)

The “tl;dr” is that I now have a JavaFX-based video player tool, thanks to 
Caprica Software, that can play a wide variety of video formats well and can be 
easily modified to support my organization's science requirements. I’ve linked 
a YouTube video of the video player app, playing a ProRes 422 encoded QuickTime 
video and communicating with another annotation application. Thanks to the 
shared buffer the video playback is smoooth. https://youtu.be/FKeuG8-UYC0

Again thanks for your work. Stay well!

Brian Schlining
Software Engineer
P (831) 775-1855   F (831) 775-1620


Monterey Bay Aquarium Research Institute
7700 Sandholdt Road, Moss Landing CA 95039
www.mbari.org
Advancing marine science and engineering to understand our changing ocean.

Re: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events

[Michael Paus]

On Thu, 2 Apr 2020 14:55:35 GMT, Kevin Rushforth  wrote:

> As noted in the JBS issue, this bug is a result of a deliberate change by 
> Apple that affects applications (in this case
> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two 
> methods that we are relying on,
> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation 
> warning or any other indication at compile
> time or runtime that these methods are ineffective. They just stopped calling 
> them. It is documented in their developer
> guide:
> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc)
> Note that it's the version of the MacOSX SDK that the JDK is linked with that 
> matters. JavaFX gesture notification
> works when run on a JDK that was linked against the 10.10 SDK or earlier 
> (regardless of what MacOSX SDK was used to
> link the JavaFX libraries). JavaFX gesture notification fails when run on a 
> JDK that was linked against the 10.11 SDK
> or later.   The solution, as indicated in the Apple documentation referred to 
> above, is to use the phase information
> from gesture events to track when to call begin / end gesture.  The fix does 
> the following things: 1. Removes the
> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in 
> `GlassView2D` and `GlassView3D` 2. Calls new
> local methods from each gesture to track when to call the associated 
> `GlassViewDelegate` notification methods,
> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent`  I've tested this 
> on macOS 10.13.6 and 10.15.3 (Catalina) and
> the attached program now runs correctly. I also tested the GestureEvent 
> sample in Ensemble8 and it reproduces the
> problem before the fix and works correctly after the fix.  I instrumented the 
> code with print statements (which I have
> since reverted) and verified that the stream of events is as expected, and 
> matches JDK 8u241 with bundled FX.

Marked as reviewed by mpaus (Author).

-

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

Re: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events

[Michael Paus]

On Fri, 3 Apr 2020 12:35:35 GMT, Kevin Rushforth  wrote:

>> I've built a fresh JFX, with your changes applied to master, this morning. I 
>> can confirm that the primary bug seems to
>> be fixed with these changes but I have observed some behaviour where I am 
>> not sure whether it is correct or whether my
>> expectation is just wrong.  1. The total delta values are now accumulated 
>> correctly for the regualar scroll events but
>> not for the following generated inertia events. They are still equal to the 
>> delta values. Is that according to the
>> specification? From a practical point of view a programmer who relies on the 
>> total delta values is probably much
>> surprised if the total delta is reset by the inertia events.  2. Is the 
>> touch-count field only valid for touch-events
>> or why is it always zero?  3. The mouse-wheel behaviour is still wrong 
>> because the total-deltas for mouse-wheel
>> generated scroll-events is still not 0 but this has probably another root 
>> cause.
>
> These are all separate issues that could be explored with follow-on bugs. I'm 
> not sure what the right behavior is for
> these or whether there is enough information from the OS to do anything about 
> them (e.g., I suspect there is no way to
> get the touch count for these trackpad-generated gestures on macOS, nor do I 
> really think it would be useful).  You
> might file a follow-on issue for 1 and 3.
> Would you be able to review this? If not I'll ask @johanvos or @pankaj-bansal 
> to be the second reviewer.

I think 1. is more a point for discussion and I am also not sure what is right 
or wrong but 3. is IMHO a bug,
especially because the documentation is so explicit about this behaviour. I'll 
file a new issue for that.

What would I have to do to formally review this? I haven't done that before.

-

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

Re: RFR: 8236971: [macos] Gestures handled incorrectly due to missing events

[Michael Paus]

On Thu, 2 Apr 2020 22:04:55 GMT, Kevin Rushforth  wrote:

>> As noted in the JBS issue, this bug is a result of a deliberate change by 
>> Apple that affects applications (in this case
>> the JDK) linked against MacOSX 10.11 SDK or later -- they no longer call two 
>> methods that we are relying on,
>> `beginGestureWithEvent` and `endGestureWithEvent`. There is no deprecation 
>> warning or any other indication at compile
>> time or runtime that these methods are ineffective. They just stopped 
>> calling them. It is documented in their developer
>> guide:
>> [developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent](https://developer.apple.com/documentation/appkit/nsresponder/1526368-begingesturewithevent?language=objc)
>> Note that it's the version of the MacOSX SDK that the JDK is linked with 
>> that matters. JavaFX gesture notification
>> works when run on a JDK that was linked against the 10.10 SDK or earlier 
>> (regardless of what MacOSX SDK was used to
>> link the JavaFX libraries). JavaFX gesture notification fails when run on a 
>> JDK that was linked against the 10.11 SDK
>> or later.   The solution, as indicated in the Apple documentation referred 
>> to above, is to use the phase information
>> from gesture events to track when to call begin / end gesture.  The fix does 
>> the following things: 1. Removes the
>> `beginGestureWithEvent` and `endGestureWithEvent` responder methods in 
>> `GlassView2D` and `GlassView3D` 2. Calls new
>> local methods from each gesture to track when to call the associated 
>> `GlassViewDelegate` notification methods,
>> `sendJavaGestureBeginEvent` and `sendJavaGestureEndEvent`  I've tested this 
>> on macOS 10.13.6 and 10.15.3 (Catalina) and
>> the attached program now runs correctly. I also tested the GestureEvent 
>> sample in Ensemble8 and it reproduces the
>> problem before the fix and works correctly after the fix.  I instrumented 
>> the code with print statements (which I have
>> since reverted) and verified that the stream of events is as expected, and 
>> matches JDK 8u241 with bundled FX.
>
> @arapte Can you be one of the reviewers?
> 
> @mipastgt I ran it against your test application, but if you have other tests 
> you could run, that would be helpful.

I've built a fresh JFX, with your changes applied to master, this morning. I 
can confirm that the primary bug seems to
be fixed with these changes but I have observed some behaviour where I am not 
sure whether it is correct or whether my
expectation is just wrong.

1. The total delta values are now accumulated correctly for the regualar scroll 
events but not for the following
generated inertia events. They are still equal to the delta values. Is that 
according to the specification? From a
practical point of view a programmer who relies on the total delta values is 
probably much surprised if the total delta
is reset by the inertia events.

2. Is the touch-count field only valid for touch-events or why is it always 
zero?

3. The mouse-wheel behaviour is still wrong because the total-deltas for 
mouse-wheel generated scroll-events is still
not 0 but this has probably another root cause.

-

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

Strange window snapshots

[Michael Paus]

Hi,

I am just debugging a JavaFX application which behaves strangely. 
Occasionally I am getting

strange error messages like this:

2020-03-29 17:43:34.485 java[6134:499599] 
-[NSPersistentUIWindowSnapshotter 
writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 
0 == ftruncate(fd, finalFileSize) failed on line 797: No such file or 
directory
2020-03-29 17:43:34.486 java[6134:499599] 
-[NSPersistentUIWindowSnapshotter 
writeWindowSnapshot:length:width:height:bytesPerRow:toFile:inDirectory:encryptingWithKey:uuid:checksum:fd:]: 
0 == ftruncate(fd, fileLength) failed on line 868: No such file or directory


I am wondering now who or what is trying to do window snapshots of my 
machine?
It seems I am only seeing this because of some error. Otherwise I would 
not have even

noticed this.

Can anybody here provide me with some insight?

I am on
macOS 10.14.6
OpenJDK 15-ea+14-561
OpenJFX 15-ea+2

Michael

Re: PixelBuffer API threading model?

[Michael Paus]

Am 25.02.20 um 15:51 schrieb Neil C Smith:

In there, we have a small amount of locking between the
GStreamer callback and the OpenGL thread to cover buffer swap and
texture upload.  Being able to do likewise with the PixelBuffer API,
to swap or null the underlying buffer, would cover both use cases
here?  Swapping the underlying buffer also makes sense for a number of
APIs like GStreamer that ping pong between various memory locations,
otherwise we need to do some careful image caching.


The API can do some limited form of buffer swapping. I did this for a
proof of concept demo recently. Whether this works or not depends
on how much control you have on the allocation of the native buffer.

What I did was to allocate a contiguous native buffer which was twice
as large as needed for the image. Let's say the image was 1000x500 pixels.
I then allocated a buffer for 1000x1000 pixels.

I then could define in C two addresses for two buffers. The first one
at offset 0 and the second one in the middle of the memory.
The two addresses can then be forwarded independently to the native
renderer. When you now get a notification from your native renderer
that one of theses buffers has been written, you can tell that to the
PixelBuffer API in the callback function by appropriately setting the
viewport. You have to set the viewport to (0, 0, 1000, 500) or
(0, 500, 1000, 500) depending on which buffer part you have written.

This concept could even be extended to more than two buffers.
The key point is that the allocated memory must be contiguous.

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Michael Paus]

In this case I would also vote for #2. Your comment astonishes me 
nevertheless because
I have never received any JavaFX TouchEvents on my Mac, so I won't miss 
them. As far as
I know they are only generated by real touch screens but NOT by track 
pads, or have I
missed something here? This is also consistent with the comment from 
Sebastian.
I am not aware of any Mac which has a touch screen, so it is quite 
unlikely that

someone has ever used them.

Am 30.01.20 um 19:28 schrieb Kevin Rushforth:
This affects TouchEvents generated via low-level native touch events, 
including those generated by a trackpad. GestureEvents still work. In 
particular, the HelloGestures app still works: even with low-level 
touch events disabled, I can use the trackpad to rotate and zoom and 
the app picks it up fine.


Mouse events, including trackpad scrolling events, are not affected at 
all by this.


-- Kevin


On 1/30/2020 9:31 AM, Michael Paus wrote:
Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. 
The effect of this bug is that a scary dialog is shown for all users 
the first time they run a JavaFX application and move the mouse is 
moved into the JavaFX window. It also is reported to block apps from 
being accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just 
differently enough (it tracks events delivered to a specific view, 
whereas the current code is implemented using a global monitor and a 
global set of touch points), that it would be too risky to change it 
this late in the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, 
I wanted to get some input from Mac users on the list. I can think 
of the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but I 
don't really like that idea, and I'm not sure how useful it would be 
anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the 
application requests them -- this would require new interfaces in 
Glass, isn't risk free, and doesn't solve the dialog problem for 
those apps that do use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it 
doesn't really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8231513

Re: Scary keystroke logging dialog on macOS 10.15 Catalina (JDK-8231513)

[Michael Paus]

Just to clarify the implications of this issue: Are you only talking 
about the JavaFX TouchEvents
or would disabling them also affect all GestureEvents and synthesized 
MouseEvents when you are

working with a trackpad?

Am 30.01.20 um 17:47 schrieb Kevin Rushforth:

To: Mac app developers / users

I started looking into JDK-8231513 [1] -- "JavaFX cause Keystroke 
Receiving prompt on MacOS 10.15 (Catalina)" -- a couple days ago. The 
effect of this bug is that a scary dialog is shown for all users the 
first time they run a JavaFX application and move the mouse is moved 
into the JavaFX window. It also is reported to block apps from being 
accepted in the Apple store.


This bug is caused by a change in macOS 10.15 to require additional 
permissions for using CGEventTap, which JavaFX uses to track touch 
events.


The suggested replacement API, 
NSEvent::addLocalMonitorForEventsMatchingMask, works just differently 
enough (it tracks events delivered to a specific view, whereas the 
current code is implemented using a global monitor and a global set of 
touch points), that it would be too risky to change it this late in 
the release.


Since there isn't an easy / safe fix that is feasible for JavaFX 14, I 
wanted to get some input from Mac users on the list. I can think of 
the following possibilities for JavaFX 14:


1. Do nothing (defer the bug to FX 15)
2. Disable touch events completely if running on macOS 10.15 (or 
later) -- we could consider a system property to re-enable it, but I 
don't really like that idea, and I'm not sure how useful it would be 
anyway since setting that flag would cause the scary dialog again.
3. Defer enabling of touch events until the first time the application 
requests them -- this would require new interfaces in Glass, isn't 
risk free, and doesn't solve the dialog problem for those apps that do 
use touch.


I'm leaning towards option #2 (without the system property to force 
enable it), but wanted to get a sense from app developers as to 
whether that would be more of a problem than doing nothing (i.e., 
option #1). I only listed option #3 for completeness, since it doesn't 
really solve the issue.


Whatever we do for 14, the solution for 15 will very likely be to 
switch to tracking per-View (per Window) touch events, either 
directly, or maybe using local event monitoring.


-- Kevin

[1] https://bugs.openjdk.java.net/browse/JDK-8231513

Re: [EXTERNAL] Explanation of different scaling factors anywhere?

[Michael Paus]

I am wondering whether this kind of scaling should actually be done on
an application basis. On desktop computers this is normally achieved via
some system setting of the monitor scaling. I think most people just want
a consistent scaling across all applications and so there is just no need
in general for an individual scaling. Just for very specific cases this may
be useful, e.g., to scale the text size of an editor window in Eclipse
where this can be done like in a browser via Cmd+/-. In a browser you
only need this feature because web-sites are so inconsistent in their
styling, which is normally not the case for desktop applications.

Just my two €ent


Am 30.01.20 um 17:29 schrieb Mike Hearn:

Yes, a scale transform doesn't affect layout. That's the issue. Browser
zoom scales fonts, images and widgets but in a way that affects layout
bounds, not only render bounds.

As far as I can tell there's no way to do a zoom or scale that affects
layout bounds with the public JavaFX API. Exploring why not and what could
work is how I ended up getting a bit lost in the weeds of all the different
scale factors. It *feels* like one of them should be applicable if only it
was public API. But I can't quite figure out which or how exactly it'd
work. If nobody else has ever examined this task (it seems not) then I
guess I can just compile my own JFX and experiment with forcing the
different factors and ratios to see what happens. I'm not sure the results
would be stable or portable though.




On Tue, Jan 28, 2020 at 11:09:04, Tom Schindl 
wrote:


I think that can not work because layouts don't take the scale factor into
account nor does stuff like ScrollView but i could be wrong.

Tom

On 27.01.20 17:29, David Grieve wrote:

Wouldn't this just be a scale transform?

-Original Message-
From: openjfx-dev  On Behalf Of
Mike Hearn
Sent: Monday, January 27, 2020 11:00 AM
To: openjfx-dev@openjdk.java.net
Subject: [EXTERNAL] Explanation of different scaling factors anywhere?

Hello,

A feature I often miss when using non-web GUIs is support for browser
style zooming. In JavaFX it is quite easy to specify all font sizes in
terms of "ems", relative sizes ("largest") or percentages and then adjust
the base font size on a root node inside key handlers. This works OK but
doesn't do much for images or other controls, and of course most JavaFX GUI
code specifies sizes in terms of pixels.

There are various scaling factors applied to pixel sizes. There is the
per-node scaling transform, but this doesn't affect layout so isn't
comparable to what browsers do. There's a per-screen DPI, there's a
"platform scale", there's a
"render scale" and then there's a "ui scale". These seem related to
hidpi/retina support and are all internal (for the purposes of this
question I'm happy to modify JavaFX itself).

Render scale seems to affect resolution without affecting positions or
layout, so that's not quite what I want. UI scale sounds promising but
isn't documented and I couldn't quite figure it out by reading the code,
though I could just fiddle with it and see what happens.

It feels like someone probably explored this before now. Is there a way to
effectively expand the size of every node without altering the size of the
containing viewport, to get browser-style layout affecting zoom? If not,
has anyone explored the complexity of the modifications required?

thanks,
-mike

--
Tom Schindl, CTO
BestSolution.at  EDV Systemhaus GmbH
Salurnerstrasse 15. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: Release roadmap for 2 already-merged TableView PRs

[Michael Paus]

Am 28.01.20 um 12:49 schrieb Ed Kennard:

It looks like the first opportunity to benefit from both changes is to wait for 
the upcoming Java 14 pre-release Feb 6th - is that on schedule, and please 
could I try that out?  Then am I correct in thinking it will be officially 
published at AdpotOpenJDK on March 17th?


Why don't you try that out right now? The pre-releases for OpenJFX 14 
and 15 are available

here  and also via Maven/Gradle.

As this is all JFX you do not even need anything beyond JDK 11 although 
the pre-releases
for that are also available here  and 
.


Michael

Re: [Rev 01] RFR: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size

[Michael Paus]

On Thu, 16 Jan 2020 13:56:44 GMT, Frederic Thevenet 
 wrote:

>> I think the proposed code changes are wrong in case that `height / 
>> maxTextureSize` is an exact integer. (Same for width). I normally add the 1 
>> only if `height  % maxTextureSize != 0`
> 
> Indeed, substituting the floating math for integer math requires an extra 
> test on the remainder to be correct. 
> Since this code isn't located in a tight loop, I'm not sure this optimization 
> is worth making the code less straight forward. What do you all think?

I think it is not worth it.

-

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

Re: [Rev 01] RFR: 8088198: Exception thrown from snapshot if dimensions are larger than max texture size

[Michael Paus]

On Thu, 16 Jan 2020 10:55:38 GMT, Ambarish Rapte  wrote:

>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 1306:
>> 
>>> 1305: int verticalTileNb = (int) Math.ceil(height / (double) 
>>> maxTextureSize);
>>> 1306: int horizontalTileNb = (int) Math.ceil(width / (double) 
>>> maxTextureSize);
>>> 1307: for (int i = 0; i < horizontalTileNb; i++) {
>> 
>> A suggestion for this arithmetic.
>> int verticalTileNb = height / maxTextureSize + 1;
>> int horizontalTileNb = width / maxTextureSize + 1;
>> This will avoid the type casting and floating point operations. However I 
>> leave it to you to change or not.
> 
> Assuming `Nb` in `verticalTileNb` stands for number, I would recommend to 
> change the names as `numVerticalTiles` and `numHorizontalTiles`

I think the proposed code changes are wrong in case that `height / 
maxTextureSize` is an exact integer. (Same for width). I normally add the 1 
only if `height  % maxTextureSize != 0`

-

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

Re: [openjdk/jfx] 8234712: Add pivot properties for scale and rotation in Node, ScaleTransition and RotateTransition (#53)

[Michael Paus]

I don't think there are clearly right or wrong answers to all these 
questions,

so I would just like to provide a view thoughts on this.

The governing principle should be a principle of "least surprise" from a 
users

point of view. That means we should not make things more complicated as
they already are and should always keep the practical use-cases in mind.
If you need full flexibility, you can always use the explicit transforms.

We currently have the notion of the "Node's center" which is used for 
scaling

and rotation and I think we should stick to that. The documentation later
explains that "The pivot point about which the rotation occurs is the center
of the untransformed layoutBounds." which is a completely arbitrary decision
because, e.g., from a mathematically point of view the geometric center 
of the
node would seem to be more natural but is more difficult to compute for 
general
shapes. So, we should just extend this scheme in such a way that the 
user can

replace the single computed center with a single user-defined center
specified in untransformed coordinates. Introducing two separate centers
for rotation and scaling is, to my opinion, just academic without any 
practical

use-case and in the end much more complicated for the user.

I would also specify this center point as a Point3D for two reasons:
1. Three doubles always use their full space even if you don't need them.
2. Using Double.NaNs as a switch between computed and user-provided center
    is just confusing and error-prone.
    What would be the meaning of setting x to some value but leaving y 
and z as

    NaN? Would you implicitly set them to 0.0 or use the computed values or
    would you discard this user setting completely and use all the 
computed
    values if any of the components is NaN? I bet most users will 
forget to set the
    Z-value anyway if they are thinking 2D. A simple null value is much 
easier

    to handle and explain.

Just my two €ent.

--Michael

Am 16.12.19 um 03:06 schrieb Nir Lisker:

Replying on the mailing list to the questions raised on GitHub.

The state of whether to use the computed center pivot or the value of the

pivot attribute is implicit with no way for an application to know which it
is, and no way to set it back to using the computed center (i.e., the state
is sticky once you set it). Perhaps if you defined a null value as meaning
"computed center" then an app could at least reset it to the "computed
center" state, although there would still be no way for the app to know
that it was in that state.


In the JBS issue  I
alluded to this in point 5. I think that null should represent the default
(node center). However, if we use 3 doubles instead of a Point3D we might
need to use Double.NaN for this instead, which would also be the default
for this case. The docs will explain this.

Do we need separate properties for scale pivot and center pivot?
I say yes, otherwise the enhancement will be very limited. I think of this
enhancement as adding pivot control to Rotate/Scale transitions, and adding
them to Node is a necessary (and desirable) step.

... you need to worry about what coordinate space the rotation pivot is

defined in. Perhaps if the rotation pivot were defined in unscaled space,
it might work.


Isn't it already? If I set the rotation pivot to the edge of the node, then
scale it down, then rotate, the rotation pivot would be outside of the
node's boundaries. In scaled space it would still be on the edge. Or did I
misunderstand you? In any case, I don't think that there's a single correct
answer here.

Should the pivot be specified as a Point3D or 3 separate doubles? Separate

doubles... there would be no out-of-band null value to use


See my point above about Double.NaN.
The doubles vs Point3D is an important choice. We might want to look into
the future even where Point3D (and 2D) could be made into an Inline class
with Valhalla, which will help with the performance aspect. Binding to one
of the coordinates is sill a problem there, however.

On Sat, Dec 14, 2019 at 6:25 PM Kevin Rushforth 
wrote:


This will need discussion on the openjfx-dev mailing list. Here are the
questions that need to be resolved:

1.

The state of whether to use the computed center pivot or the value of
the pivot attribute is implicit with no way for an application to know
which it is, and no way to set it back to using the computed center (i.e.,
the state is sticky once you set it). Perhaps if you defined a null value
as meaning "computed center" then an app could at least reset it to the
"computed center" state, although there would still be no way for the app
to know that it was in that state.
2.

Do we need separate properties for scale pivot and center pivot? A
single pivot property would be easier to define, but wouldn't allow you to
set it from a RotationTransition and a ScaleTransition if 

Re: Blank stages when running JavaFX app in a macOS virtual machine

[Michael Paus]

Hi,
maybe you lost the response mail or it went into your trash.
I guess this is your bug report in the JBS.
https://bugs.openjdk.java.net/browse/JDK-8235627
--Michael

Am 10.12.19 um 11:33 schrieb thevenet.f...@free.fr:

Hi,

I've submitted bug report via https://bugreport.java.com/bugreport/ regarding 
the issue below about a week ago but I haven't heard from it yet.
I understand this might not be the best place to inquire about it, but since 
this prevents me from submitting a PR (as I don't have an issue number) I was 
hoping someone here could offer some guidance on how to get this moving forward.

Many thanks,
Fred.

- Mail original -
De: "thevenet fred" 
À: "Kevin Rushforth" 
Cc: "openjfx-dev" 
Envoyé: Mardi 3 Décembre 2019 18:46:57
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

Ok thanks, will do that.

Regards,
Frederic Thevenet

- Mail original -
De: "Kevin Rushforth" 
À: "openjfx-dev" 
Envoyé: Mardi 3 Décembre 2019 18:35:49
Objet: Re: Blank stages when running JavaFX app in a macOS virtual machine

A new follow-on bug ID will be needed. We never reopen a JBS issue once
it has been resolved as fixed by a changeset that has been pushed.

-- Kevin


On 12/3/2019 7:11 AM, thevenet.f...@free.fr wrote:

Hello,

When running a JavaFX application in macOS guest VM, the main stage is 
completely blank, with the following errors: CGLChoosePixelFormat error: 10002, 
CGLCreateContext error: 10002
This behavior was observed with a macOS 10.15 guest OS on both VMWare player 
and VirtualBox, on a Windows 10 host.

This is an old issue that has already been reported several times (notably as 
JDK-8154852) but is claimed to have been fixed by JDK-8154148.
However the fix provided by JDK-8154148 is incomplete; while it does fix a JVM 
crash, it doesn't prevent an incorrect pixel format to be retrieved, which is 
the root cause for the stage being empty.

The problematic code is located at #96 in GlassView3D.m:

095: CGLError err = CGLChoosePixelFormat(attributes, , );
096: if ((err == kCGLNoError) && (npix == 0))
097: {
098:   const CGLPixelFormatAttribute attributes2[] =
099:   {
100: kCGLPFAAllowOfflineRenderers,
101: (CGLPixelFormatAttribute)0
102:   };
103:   err = CGLChoosePixelFormat(attributes2, , );
104: }


In a comment in JDK-8154148, the following claim is made: "[...] an error happens is 
when something bad or invalid has occurred. An unsatisfied pixel format request is indicated 
by npix is 0 and pix is NULL. Hence I feel it is a cleaner and clearer logic to request a 
different format when npix is 0 and err is kCGLNoError." 
(https://bugs.openjdk.java.net/browse/JDK-8154148?focusedCommentId=13980465=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-13980465)

   From what I could observe, this is not necessarily true; in this case where 
a pixel format satisfying the initial conditions could not be found, the return 
code is kCGLBadPixelFormat (10002); which means we don't try to get a pixel 
format with less restrictive condition.
This suggests that a better condition for the second call to CGLChoosePixelFormat (line #103) should be 
"if (pix == NULL)" instead of "if ((err == kCGLNoError) && (npix == 0))"
This is further supported by a sample in Apple developer's documentation on how 
to choose a pixel format: 
https://developer.apple.com/library/archive/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_pixelformats/opengl_pixelformats.html

I have verified that this change produces the expected behavior and I propose 
to submit a PR with this change (I have already signed the OCA)

A quick question before I do, however; should I file a new issue prior to 
submitting a PR or is it better that someone with privileges reopens 
JDK-8154148?

Regards,

Frederic Thevenet

Re: JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Michael Paus]

flection/jni configuration,
platform-specific static libraries, including resources and

bundles...).

This is why we created Gluon Substrate [3], which does most of this

work:

Developers use a maven plugin [4] (gradle will be ready soon too) and

this

is used in the samples [2].

If you use GraalVM native-image without all the parameters that Gluon
Substrate adds, you will most likely create a "fallback-image" that

still

require a JVM and some other resources to be available at runtime, and

this

can give strange results. While I don't exclude JavaFX bugs will

surface

using this approach, I think it's more likely you're seeing issues due

to

this "mixed mode".

- Johan

[1]


https://gluonhq.com/gluon-substrate-and-graalvm-native-image-with-javafx-support/

[2] https://github.com/gluonhq/client-samples
[3]  https://github.com/gluonhq/substrate
[4] https://github.com/gluonhq/client-maven-plugin

On Wed, Nov 20, 2019 at 10:22 PM Michael Paus  wrote:


Hi,

I would just like to know where JavaFX problems or bugs should be

reported

which are strictly related to running on the just released GraalVM

19.3

with
Java 11 support. Should they go into the regular JBS or should they

be

reported
elsewhere?

For example: I have observed that a large JavaFX application seems to

work

correctly at first but then suddenly all text on all controls turns
white and
white on white or light grey is not really readable anymore. I've

never

observed
such a behaviour on any other VM before. There is also no error

message or

warning associated with this. It just happens.

There even seem to be more issues when you try to use native-image.

--Michael

JavaFX-Bugs on GraalVM 19.3 (Java 11)

[Michael Paus]

Hi,

I would just like to know where JavaFX problems or bugs should be reported
which are strictly related to running on the just released GraalVM 19.3 with
Java 11 support. Should they go into the regular JBS or should they be 
reported

elsewhere?

For example: I have observed that a large JavaFX application seems to work
correctly at first but then suddenly all text on all controls turns 
white and
white on white or light grey is not really readable anymore. I've never 
observed

such a behaviour on any other VM before. There is also no error message or
warning associated with this. It just happens.

There even seem to be more issues when you try to use native-image.

--Michael

Re: RFR: 8087980: Add property to disable Monocle cursor

[Michael Paus]

+1

Am 13.11.19 um 21:50 schrieb Dell Green:

On Wed, 13 Nov 2019 19:57:04 GMT, Kevin Rushforth  wrote:


On Tue, 29 Oct 2019 11:31:18 GMT, Kevin Rushforth  wrote:


On Tue, 29 Oct 2019 10:10:32 GMT, Dell Green 
 wrote:


On Tue, 29 Oct 2019 09:53:28 GMT, Johan Vos  wrote:


On Tue, 8 Oct 2019 12:03:46 GMT, Kevin Rushforth  wrote:


On Tue, 8 Oct 2019 12:03:42 GMT, Dell Green 
<12861109+dellgr...@users.noreply.github.com> wrote:


Often on embedded systems a cursor is not a valid input modality. On some of these 
systems, when the javafx toolkit initialises the native hardware cursor, it produces 
artefacts which can be seen on screen (in the framebuffer for example). This change adds 
a system property "monocle.cursor.enabled" that can disable the creation of a 
native cursor in each of the Monocle NativePlatform implementations in favour of a 
NullCursor which is a no-op implementation of the NativeCursor abstract class that all 
native cursors have to implement.

NullCursor class already existed and was being returned for some 
implementations like AndroidPlatform and HeadlessPlatform. This change builds 
upon that and conditionally returns NullCursor for all platforms.

A system property "monocle.debugcursor" has also been added to turn on logging 
of which NativeCursor has been selected when the toolkit initialises.



Commits:
  - cfbbc7dd: JDK-8087980: Add property to disable Monocle cursor

Changes: https://git.openjdk.java.net/jfx/pull/5/files
  Webrev: https://webrevs.openjdk.java.net/jfx/5/webrev.00
   Issue: https://bugs.openjdk.java.net/browse/JDK-8087980
   Stats: 49 lines in 8 files changed: 40 ins; 0 del; 9 mod
   Patch: https://git.openjdk.java.net/jfx/pull/5.diff
   Fetch: git fetch https://git.openjdk.java.net/jfx pull/5/head:pull/5

This has not yet been reviewed. It will need at least one reviewer with a 
Reviewer role in the project.



Disapproved by kcr (Lead).

Is this PR open for review now? Or will a new PR be created?

this is ready for review form my perspective. :)

The Skara tooling bug in question has been fixed, so yes this is ready for 
review.

I have no particular issue one way or the other on this. I will defer the 
review to @johanvos

As a follow up, if its desirable for javafx to be used in IOT/embedded devices, 
 we should fix this issue, otherwise it doesn't look as slick on startup when i 
put it next to competing devices. :)

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

Re: FXMLLoader: not supplying filename to script engine, not supplying event object as argument to script

[Michael Paus]

Hi,
have you considered directly contributing your proposed change via a PR on
? According to my experience this may speed
up things considerably but don't forget to follow the procedures as 
outlined in

.
--Michael

Am 13.11.19 um 15:14 schrieb Rony G. Flatscher:

Hmm, not getting any feedback so far, so wondering if there are currently any 
Java developers who
take advantage of the ability of FXMLLoader to have FXML controllers 
implemented in any of the Java
javax.script languages?

For those, who use scripting languages for FXML controllers the request that 
FXMLLoader adds both
entries, ScriptEngine.FILENAME (for debugging, logging) and ScriptEngine.ARGV 
() (for making the
event object available directly as an argument) into the engine Bindings, 
should be quite helpful
while developing and running the scripts.

[Personally I am using the scripting engine ooRexx successfully for teaching oo 
programming from
scratch to JavaFX in a single semester (four hour lecture, eight ECTS) at a 
Business Administration
university. So these two missing features in the current FXMLLoader support for 
FXML controllers
would help tremendously, especially in case of coding errors as currently it is 
not clear from which
file the script that has an error comes from, making it extremely cumbersome 
and time consuming in
JavaFX applications that use multiple and complex FXML files.]

Therefore I would kindly ask interested committers for mentoring the proposed 
changes. Enclosed
please find a simpler version of the patch that adds these missing features to 
the ENGINE_SCOPE
Bindings in the three locations where ScriptEngine.eval() gets invoked (it ).

To comment this simple patch, maybe I should add a few remarks such that the 
context becomes clear:

   * invoking a script via ScriptEngine.eval() will always be accompanied with 
a ScriptContext that
 usually maintains two Bindings (Maps):

   o one, GLOBAL_SCOPE Bindings, for global entries (used e.g. for putting 
the FXML elements that
 have an fx:id attribute defined, such that scripts can get access to 
them, independent of a
 particular ScriptEngine) which can also be used for sharing values 
among different script
 invocations,

   o one, ENGINE_SCOPE Bindings, usually used for individual invocations.

   * while a FXML file gets processed sequentially by the FXMLLoader elements 
in the form of
 "" will cause invoking the 
ScriptEngine.eval(Reader): this
 patch fetches the ENGINE_SCOPE Bindings and puts the value 
"someScript.ext" with the key
 ScriptEngine.FILENAME into it (cf. "@@ -1558,6 +1558,9 @@ public class 
FXMLLoader" and "@@
 -1582,6 +1585,8 @@ public class FXMLLoader" in the patch),

   * if an event handler gets defined (e.g. with the event attribute 
"") the FXMLLoader creates a ScriptEventHandler and stores 
"someScript" and
 the ScriptEngine for executing that script whenever the event fires.

   o When an event fires, the current implementation creates a copy of the 
current ENGINE_SCOPE
 Bindings from the ScriptEngine's ScriptContext, adds its entries to it 
after saving the
 entry "event" with the ActionEvent object in it. It then changes the 
ScriptEngine's current
 ScriptContext such that it now uses the new copy of the Bindings as 
its ENGINE_SCOPE
 Bindings, runs the script using eval() and then restores the 
ScriptContext ENGINE_SCOPE
 Bindings.

   o The supplied patch (cf. "@@ -1675,30 +1680,28 @@ public class 
FXMLLoader") instead will
 create a copy of the ENGINE_SCOPE Bindings only once at creation time 
(and puts the
 appropriate ScriptEngine.FILENAME into it using the name of the FXML 
file that defines the
 event script attribute) and will reuse that Bindings each time the 
handler gets invoked,
 after putting the actual "event" object and the respective 
ScriptEngine.ARGV entry into it.
 Using ScriptEngine.eval(String,Bindings) will use the supplied 
Bindings as the ENGINE_SCOPE
 Bindings for this invocation only, such that no restore is necessary 
upon return.

As only entries get added to the engine Bindings that have not been used by 
FXMLLoader this simple
patch should not affect existing scripts. The patch has been tested and works.

Maybe it helps the cause for applying this patch, if I point out that I have 
been active in a number
of opensource projects, including Apache's BSF which led to my participation as 
an expert in JSR-223
which originally defined the javax.script framework introduced with Java 6 
(also authored a complete
ScriptEngine implementation with both, the javax.script.Compilable and the 
javax.script.Invocable
interfaces).

So looking for interested committers who would be willing to mentor this patch. 
Please advise.

---rony



On 06.11.2019 16:05, Rony G. 

Re: Bug in TreeTableView rendering

[Michael Paus]

Hi,
doesn't this again exclude all external developers from discussing 
issues with other developers?
To my opinion disabling the issue tracker defeats the whole purpose of 
using GitHub at all, or

did I misunderstand something here?
Michael


Am 30.09.19 um 14:45 schrieb Kevin Rushforth:
The official GitHub repos in the openjdk organization will not have 
the issue tracker enabled, which should help avoid this confusion.


-- Kevin 

Re: Can't execute OpenJFX app from command-line on macOS

[Michael Paus]

There are currently issues with AdoptOpenJDK on Mojave.
(https://github.com/AdoptOpenJDK/openjdk-build/issues/1211)
This also applies to 12. Try to use one of the latest nightly builds
where this bug is supposed to be fixed.
Michael

Am 16.09.19 um 20:01 schrieb Duquette, Will (US 393E):

Howdy!


I'm running on Mojave using AdoptOpenJDK 12 and OpenJFX 13.  I've built a 
simple hello world app (a label in a stackpane).  When I try to run it from the 
command line, I get this:


$ java --module-path ${PATH_TO_FX} --add-modules javafx.controls -cp 
dist/MyApp.jar myapp.App

Graphics Device initialization failed for :  es2, sw

Error initializing QuantumRenderer: no suitable pipeline found

java.lang.RuntimeException: java.lang.RuntimeException: Error initializing 
QuantumRenderer: no suitable pipeline found

at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumRenderer.getInstance(QuantumRenderer.java:280)

at 
javafx.graphics/com.sun.javafx.tk.quantum.QuantumToolkit.init(QuantumToolkit.java:244)

at javafx.graphics/com.sun.javafx.tk.Toolkit.getToolkit(Toolkit.java:260)

...

Any ideas?

The app looks like this:

package myapp;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.layout.StackPane;
import javafx.stage.Stage;

/**
   *
   * @author will
   */
public class App extends Application {
@Override
public void start(Stage stage) throws Exception {
  StackPane root = new StackPane();

  Label label = new Label("Hello, world!");

  label.setPrefWidth(200);
  label.setPrefHeight(200);

  root.getChildren().add(label);

  stage.setTitle("Hello, World");
  stage.setScene(new Scene(root));
  stage.show();
}

  /**
   * @param args the command line arguments
   */
  public static void main(String[] args) {
  launch(args);
  }
}

Re: Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError

[Michael Paus]

Hi,

did you try the suggested work-around by adding something like this to the
launch parameters of your bundled application?

-Djava.library.path=C:/go-out-of-my-way

Michael

Am 16.09.19 um 09:57 schrieb Andrea Vacondio:

Hi,
I'm trying to get some attention on this issue
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8231015
My application, PDFsam Basic, is a self contained javafx application with a
bundled jlinked AdoptOpenJDK 11.0.4, it has 5 or 6k new users every day and
very few of them are affected by this issue. In short, on Windows, the
bundled jvm tries to load some dll from a JVM installed on the system. This
is similar to
https://stackoverflow.com/questions/52906570/javafx-11-using-maven-throws-exception-windowsnativerunloopthread
and
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022713.html
but in my case there is no IDE involved, no Eclipse, no Maven.
My bug report has been quickly dismissed as "This is caused by a
configuration error on the developers machine. Closing as "Not an issue"".
I can't reply on that issue to ask details so I was hoping I could can get
some help here.
I am talking about users (not developers) with a java runtime on their
machine, they download my MSI, install it, double click the .exe (a
launch4j created exe that basically runs a java -jar using the bundle
AdoptOpenJDK) and they get the exception because the jdk tries to load a
dll from a wrong location. I am sure it's probably some "configuration
error on the user machine" but these are not techy users tweaking around
and messing with the registry, for some of them is hard to figure how to
uninstall java.
Unfortunately I cannot reproduce it on my machines.
Any idea of what "configuration error" could cause this behavior?
Thanks for the help
Andrea

Re: Proposal: Migrate official jfx repo to GitHub + Skara tooling

[Michael Paus]

Hi

Am 21.08.19 um 00:14 schrieb Kevin Rushforth:
I expect many (most?) developers will use the GitHub workflow they are 
already used to via the web interface, but there is an option for 
those who want to use the command line tools like "git pr". 


I just wanted to add that there is even a third option which is 
GitHub-Desktop.


https://desktop.github.com/

A standalone application from GitHub which simplifies some of the work.

(A pitty it is written in Electron and not in JavaFX ;-))

Michael

RFR: JDK-8229890 WritableImage update fails for empty region

[Michael Paus]

Hi,

please review my fix for JDK-8229890.



https://github.com/javafxports/openjdk-jfx/issues/567

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

Michael

Re: Concatenating transforms to scale positions but not objects

[Michael Paus]

Nir is right here but if you could ask your question on StackOverflow
I'd be willing to comment on it because I was facing a very similar
problem in my projects and I might provide some ideas.

Am 11.08.19 um 01:25 schrieb Nir Lisker:

I think that this is a better question for StackOverflow. This is a
development mailing list.

- Nir

On Sat, Aug 10, 2019 at 6:53 PM Mark Raynsford  wrote:


On 2019-08-06T19:11:42 +0100
Mark Raynsford  wrote:


Hello!

I realize the subject is somewhat convoluted. I'm putting together
something that bears a passing resemblance to a DAW such as Ardour:

Given the tumbleweeds and sounds of crickets, I'm guessing that I
expressed my question rather poorly.

Here's what I'm trying to do: I'm trying to set up a pane with a
transform such that I can place objects inside that pane using
positions that don't correspond to JavaFX "scene pixels". For example,
1024 units in my coordinate system might correspond to 1 "scene pixel"
(is there a better name for the units that JavaFX uses?). However: The
objects that are *inside* the objects that I add to the pane want to
work in "scene pixels" (for example; Labels seem to want to work in
pixel positions when rendering text).

Here's a GitHub gist that gives a short example of this:

https://gist.github.com/io7m/20b071e11da2dcd96896a43fad6df644

I create one container group (actually a Pane) that adds a transform
such that 1 unit == 32 pixels. I add objects to this container. Each
object I add has an *external* pane with a size and position specified
in units, and an *internal* pane that solely exists to invert the scale
of the transform of the *external* pane. Inside this *internal* pane, I
can add Labels and so on and these all render correctly.

I set up bindings between the transforms so that I can effectively
scale and pan the scene by adjusting the transform on the group
container. However: Something about this setup seems to be confusing
something inside JavaFX; the results I'm seeing onscreen don't seem to
match what JavaFX believes the bounds of various objects are. This
causes visual issues when I try to do things like set borders on
objects, and also seems to confuse ScenicView.

Here's a shot with the container group selected (looks correct):

https://ataxia.io7m.com/2019/08/10/view0.png

Here's a shot with the *external* pane of the bottom object selected:

https://ataxia.io7m.com/2019/08/10/view1.png

Note that, although the object actually renders onscreen as the right
size (one of the pale grey boxes), ScenicView seems to believe that the
object's bounds are 1x1: They *are* 1x1, but they're 1x1 when expressed
in my custom coordinate system, not in JavaFX "scene pixels".

Here's a shot with the *internal* pane of the bottom object selected:

https://ataxia.io7m.com/2019/08/10/view2.png

This looks correct in the sense that the bounds encompass the label and
nothing else.

Am I doing something wrong here? I can't tell if I'm basically abusing
transforms or not.

--
Mark Raynsford | http://www.io7m.com

RFR: JDK-8220396: Bindings class gives a lot of unneeded 'select-binding' log messages

[Michael Paus]

Hi Kevin,

please review my fix for "JDK-8220396: Bindings class gives a lot of 
unneeded 'select-binding' log messages"


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

https://github.com/javafxports/openjdk-jfx/issues/383

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

Re: Debugging JavaFX

[Michael Paus]

Oh I see. I should have read the text more carefully. I confused local 
with internal variables.
I can indeed not see variables with a local scope inside a method and I 
also don't see the

names of parameters. They are named arg0, ... but I do see their values.
This behaviour seems to be different to the JDK sources.

Am 17.07.19 um 17:01 schrieb Kevin Rushforth:
When you say that don't see a problem, what exactly do you mean? If 
you are able to see the local variables in a production build, then 
that would in fact be surprising. The production builds, including EA 
builds, should be being built with "-PCONF=Release" which would 
exclude vars. Someone from Gluon should confirm.


-- Kevin


On 7/17/2019 7:56 AM, Michael Paus wrote:

Hi,
I don't see any problem of that kind with Eclipse, on MacOS, JavaFX 
13-ea 9 via Maven.

Michael

Am 17.07.19 um 16:45 schrieb Kevin Rushforth:
That should have been enough to enable local variable symbols. We 
have the following logic for JavaCompile tasks:


    compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? 
"source,lines,vars" : "source,lines"


IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative.

Maybe something else is stripping out the symbols.

Has anyone else debugged JavaFX recently and tried to look at local 
vars? If not, I'll take a quick look later today.


-- Kevin



On 7/17/2019 7:38 AM, Robert Lichtenberger wrote:

I'm trying to get to the bottom of some weird layout problems in my
application.

To that end I want/need to debug JavaFX classes.

But when I step into JavaFX classes I don't see local variables or
parameter names.

So I thought debug symbols are probably stripped from the official 
builds.


I rolled my own and tried

 CONF = Debug

and

 CONF = DebugNative

in gradle.properties, recompiled OpenJFX and integrated the libraries
into a little eclipse testproject.

But I still don't see parameter names or local variables.

Is there something else I need to do in order to see them?


Best regards,

Robert

Re: Debugging JavaFX

[Michael Paus]

Hi,
I don't see any problem of that kind with Eclipse, on MacOS, JavaFX 
13-ea 9 via Maven.

Michael

Am 17.07.19 um 16:45 schrieb Kevin Rushforth:
That should have been enough to enable local variable symbols. We have 
the following logic for JavaCompile tasks:


    compile.options.debugOptions.debugLevel = IS_DEBUG_JAVA ? 
"source,lines,vars" : "source,lines"


IS_DEBUG_JAVA is true if CONF is either Debug or DebugNative.

Maybe something else is stripping out the symbols.

Has anyone else debugged JavaFX recently and tried to look at local 
vars? If not, I'll take a quick look later today.


-- Kevin



On 7/17/2019 7:38 AM, Robert Lichtenberger wrote:

I'm trying to get to the bottom of some weird layout problems in my
application.

To that end I want/need to debug JavaFX classes.

But when I step into JavaFX classes I don't see local variables or
parameter names.

So I thought debug symbols are probably stripped from the official 
builds.


I rolled my own and tried

 CONF = Debug

and

 CONF = DebugNative

in gradle.properties, recompiled OpenJFX and integrated the libraries
into a little eclipse testproject.

But I still don't see parameter names or local variables.

Is there something else I need to do in order to see them?


Best regards,

Robert

Re: Fwd: JavaFX 11 on Raspberry Pi

[Michael Paus]

You might want to have a look at https://bell-sw.com/pages/java-12/
I don't know whether the audio works but I think it should be worth a try.
Liberica already contains JavaFX, so you do not need the bits from Gluon.
Michael

Am 27.03.19 um 20:36 schrieb Thomas Manz:

Hello,

in the last months I started to do some tests with Java 11 and JavaFX 11 on
a Raspberry Pi 3. I followed this manual (http://docs.gluonhq.com/embedded/)
but unfortunately I realized that so far Gluon´s EA build of JavaFX
11-ea-25 for armv6hf does not support audio for javafx.media (
https://stackoverflow.com/questions/53906096/play-mp3-with-javafx-11-on-raspberry-pi-3
).

Last week I repeated this with the meanwhile published non-EA build of
JavaFX 11.0.2 for armv6hf but the problem still exists.

In order to get a better feeling for the situation about JavaFX on the
Raspberry Pi I would be interested in some details:
1. The comment on StackOverflow says there is something missing in Gluon´s
release - is this correct or did I make a mistake?
2. In case the problem is in Gluon´s package:
 a) do you know about plans to fix this in the near future? Maybe with
JavaFX 12?
 b) are you aware of other sources for ARM builds of JavaFX 11 (that
might support audio)?
3. Is there some kind of documentation accessible that shows what
functionalities are included / not included in JavaFX 11 for ARM or any
future releases?

Thank you very much for your help!

Best regards,
Thomas Manz

Re: JDK-8220222: specify clearly gradle project dependencies

[Michael Paus]

Hi
What is the status of Eclipse in this context?
Michael

Am 08.03.19 um 09:20 schrieb Cirujano Cuesta, Diego:

Please review the following PR:

https://github.com/javafxports/openjdk-jfx/pull/401
https://bugs.openjdk.java.net/browse/JDK-8220222


Best regards,

Diego Cirujano Cuesta
__

Diego Cirujano Cuesta
Central Software Munich
Medical Technology Business Group
ZEISS Expert Ladder - Staff

Carl Zeiss Meditec AG
ZEISS Gruppe
Kistlerhofstr. 75
81379 Munich, Deutschland

Phone: +4989909000203 Mobile: +4916099193532
diego.cirujano-cue...@zeiss.com
http://www.zeiss.com/med
__

Carl Zeiss Meditec AG
Sitz der Gesellschaft: Jena, Deutschland
Vorsitzender des Aufsichtsrats: Dr. Michael Kaschke
Vorstand: Dr. Ludwin Monz (Vorsitzender), Dr. Christian Müller (CFO)
Amtsgericht Jena, HRB 205 623, USt-IdNr: DE 811 922 737

Re: OpenJDK 8 and JavaFx for Windows 7

[Michael Paus]

Are you sure? According to this article and other sources it does 
support JavaFX:

<https://dev.karakun.com/java/openjdk/2018/11/23/amazon-corretto.html>
Search for JavaFX.

Am 06.12.18 um 15:31 schrieb Stefan Murawski:

Hi,

thanks for the coretto tip. But the MSI for the Windows JRE does not 
contain javafx.


Cheers,
Stefan

Am Do., 6. Dez. 2018 um 14:44 Uhr schrieb Michael Paus <mailto:m...@jugs.org>>:


Have a look at: https://aws.amazon.com/de/corretto/
Windows is supported and it includes JavaFX
but I don't know whether this is compatible with the old Windows 7.
Michael

Am 06.12.18 um 14:33 schrieb Stefan Murawski:
> Hi,
>
> this probably an annoying question, but I cannot find a solution.
>
> I am trying to find a JavaFX build that is compatible with
OpenJDK 8 and
> Windows.
>
> So far I tried:
> Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from
> https://chriswhocodes.com/.
>
> This works very well for Windows 10. But on Windows I cannot
start the
> application due to missing DLLS (I presume).
>
> My hunt through the internet led me to a post which basically said:
> OpenJDK 8 and JavaFx will never work on Windows 7.
> Is this true?
>
> The Reasoning behind my search is the desire to switch to an
openjdk which
> is supported a bit longer than the oracle 8 jdk, but with javafx for
> Windows integrated.
>
> The new JavaFX page only deals with JavaFx11, sadly.
>
> If there is a way to build javafx myself, so that it works with
> WIndows7/10/OpenJDK please kindly guide me to a description.
>
> Thanks for any help,
> Stefan Murwaski

Re: OpenJDK 8 and JavaFx for Windows 7

[Michael Paus]

Have a look at: https://aws.amazon.com/de/corretto/
Windows is supported and it includes JavaFX
but I don't know whether this is compatible with the old Windows 7.
Michael

Am 06.12.18 um 14:33 schrieb Stefan Murawski:

Hi,

this probably an annoying question, but I cannot find a solution.

I am trying to find a JavaFX build that is compatible with OpenJDK 8 and
Windows.

So far I tried:
Taking the AdoptOpenJDK Build for Windows 64 and JavaFX Drop-In from
https://chriswhocodes.com/.

This works very well for Windows 10. But on Windows I cannot start the
application due to missing DLLS (I presume).

My hunt through the internet led me to a post which basically said:
OpenJDK 8 and JavaFx will never work on Windows 7.
Is this true?

The Reasoning behind my search is the desire to switch to an openjdk which
is supported a bit longer than the oracle 8 jdk, but with javafx for
Windows integrated.

The new JavaFX page only deals with JavaFx11, sadly.

If there is a way to build javafx myself, so that it works with
WIndows7/10/OpenJDK please kindly guide me to a description.

Thanks for any help,
Stefan Murwaski

Re: JavaFX 11.0.1-ea+1 release

[Michael Paus]

Hi,
sorry fo the confusion. I thought I was using the 11.0.1 SDK on my Mac
but actually I wasn't. Eclipse again played a prank on me with the 
modulepath.


Am 04.11.18 um 20:26 schrieb Johan Vos:

It should.
I have the following:
javafx.version = 11.0.1-ea

Are you using an SDK or maven artifacts? For which platform?

- Johan

On Sun, Nov 4, 2018 at 4:07 PM Michael Paus <mailto:m...@jugs.org>> wrote:


My application is reporting the following values for the respective
properties:

java.runtime.version: 11.0.1+13
java.class.version: 55.0
java.version: 11.0.1
javafx.version: 11

Shouldn't "javafx.version" follow the same naming conventions as
used by
"java.version"?


Am 02.11.18 um 09:59 schrieb Johan Vos:
> Hi,
>
> We are about to release JavaFX 11.0.1, containing the fixes that
made it
> into the 11-dev repository.
> An early-access build for this is available as SDK/jmods at
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip
>

<http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip>
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
>

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip
>
> The maven artifacts are available in the usual repositories,
with version
> tag being "11.0.1-ea+1" e.g.
>
> org.openjfx:javafx-base:11.0.1-ea+1 (see
>
http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)
>
> If we don't hear major issues with this ea, it should become the
11.0.1
> release.
>
> - Johan

Re: JavaFX 11.0.1-ea+1 release

[Michael Paus]

My application is reporting the following values for the respective 
properties:


java.runtime.version: 11.0.1+13
java.class.version: 55.0
java.version: 11.0.1
javafx.version: 11

Shouldn't "javafx.version" follow the same naming conventions as used by 
"java.version"?



Am 02.11.18 um 09:59 schrieb Johan Vos:

Hi,

We are about to release JavaFX 11.0.1, containing the fixes that made it
into the 11-dev repository.
An early-access build for this is available as SDK/jmods at
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_linux-x64_bin-sdk.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_osx-x64_bin-sdk.zip

http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-jmods.zip
http://download2.gluonhq.com/openjfx/11.0.1/openjfx-11.0.1-ea+1_windows-x64_bin-sdk.zip

The maven artifacts are available in the usual repositories, with version
tag being "11.0.1-ea+1" e.g.

org.openjfx:javafx-base:11.0.1-ea+1 (see
http://repo.maven.apache.org/maven2/org/openjfx/javafx-base/11.0.1-ea+1/)

If we don't hear major issues with this ea, it should become the 11.0.1
release.

- Johan

Re: Compiling using javac

[Michael Paus]

The documentation you are looking for can be found here:
https://openjfx.io/openjfx-docs/

Am 09.10.18 um 15:32 schrieb Graham Norris:

I have an existing Java application which uses JavaFX. It is currently compiled
(on Windows) and working using Oracle's Java 10 JDK. I am now trying to get it
to compile using OpenJDK 11 and OpenJFX 11, and failing miserably!

I use the JDK's command line tools to compile the application and haven't
managed to find anything which shows how to make the combination of an existing
application, OpenJDK 11 and OpenJFX 11 compile. Basically, I can't get javac to
find and use either OpenJFX's jmods or jars.

I feel there should be somewhere I could read instructions on how to use
OpenJFX with OpenJDK 11's javac, but if there is, I just can't find it!

Any help appreciated.

Graham.

Re: how to implement delayed calculation of node/shape

[Michael Paus]

One possible solution for this would be to use an AnimationTimer.
Maintain a dirty state somewhere and check that when the AnimationTimer
gets called for the next pulse.

Am 26.08.18 um 16:59 schrieb Zsolt Kúti:

Hi,
Some of my classes extend Path or Group and constructed by non-trivial
algorithms that may use many properties, either standard (like strokeWidth)
or non-standard ones. Setting a property calculates a new state at present.
When several properties are set it means a lot of unnecessary calculations
done.

I would like to delay geometry/shape calculations similar the way
Node/Shape do. They signal their state changes by dirty flagging and on
pulse necessary synchronization does recalculations when being dirty.
However relevant methods despite being public are deprecated (tipically
ones starting with impl_) and cannot be relied upon.

Is there a way to achive that kind of design for own classes?
Thx!

Zsolt

Re: Fate of jdk.packager and jdk.packager.services?

[Michael Paus]

1. What forces you to make the switch from 8 to 11 at the same day when 
jdk11 comes out?
2. The plan is that when jdk11 comes out there will already be an EA 
version of jdk12 available which
    already contains a version of the new packager which will also work 
with jdk11 then.

    As long as this plan holds, there will be no gap.

Am 09.08.18 um 11:42 schrieb Cyril F:

I am sure the new jpackager tool will be a good substitute. But won't come 
before jdk12...

In fact we are in the current situation :
 We have a javaFX8 app distributed as a .exe with a bundled JRE.
 We are mirating to javaFX11.

My fear is that there will be a gap between javafx11 (october) and the new 
jpackager (not before jdk12) where no official and supported tool will be 
provided.

In this situation (I am sure we are not alone) what should we do ? Wait for the 
new jpackager ? or start using openjfx11 with no real certainty ? use an other 
tool ?

Cyril

Re: Fate of jdk.packager and jdk.packager.services?

[Michael Paus]

I don't know whether the following statement is still valid, but if it is,
then it may not be worth the effort to resurrect the old javapackager
if at least an EA build of the new one is so close.

On 6/27/2018 3:30 PM, Kevin Rushforth wrote:

/We're aiming to get this into JDK 12 early enough so that an EA build />/would be 
available around the time JDK 11 ships. That will allow you />/to take a jlinked 
image with JDK 11 and package it up using (the EA) />/jpackager./


Michael

Am 07.08.18 um 18:49 schrieb Kevin Rushforth:

Someone could certainly do that.

We think there is enough interest in having a standard tool that it is 
worth spending effort on a replacement tool that will be part of 
standard JDK builds, including OpenJDK builds that have never had 
javapackager. In the mean time, if a standalone build of javapackager 
works for you, then that's great.


-- Kevin


On 8/7/2018 9:16 AM, jo...@msli.com wrote:

The motivation for a new packager states a need for a a packager, but
not why the javapackager can't continue.

With all the work that went into javapackager, why can't it simple be
released for continued development outside Oracle, if they don't want to
maintain it.

The javapackager has worked well for a few years, so why reinvent a
packager with fewer features, rather than expand features, and clear 
bugs?


On 08/07/2018 05:03 AM, Lennart Börjeson wrote:
Well, while I can surely use the packager from JDK 10 and bundle my 
application with 11, I'd still miss out on the packager service, 
i.e. the application would not be able to use the UserJvmOptions.


It seems to me the packager service has been completely forgotten? 
JDK-8200758 does not mention it at all.


/Lennart


7 aug. 2018 kl. 13:45 skrev Nir Lisker :

Hi Lennart,

You should be able to use the packager from JDK 10, see 
https://bugs.openjdk.java.net/browse/JDK-8203379 
.


There is a draft for a replacement, see 
https://bugs.openjdk.java.net/browse/JDK-8200758 
.


- Nir

On Tue, Aug 7, 2018 at 12:28 PM, Lennart Börjeson 
mailto:lenbo...@gmail.com>> wrote:
I'm migrating to JDK 11 and OpenJFX 11, and would like to continue 
using the packager and the associated packager service (i.e. the 
UserJvmOptions).


AFAIK, those are gone from the available binary builds, but still 
there in the code. Is there a way to use them without resorting to 
build openjfx myself? If not, is there some alternative to the 
UserJvmOptions?



(I'm currently working around my problems by building both openjfx 
and the JDK, and bundling openjfx with the JDK, just like in the 
good old days...)


Best regards,

/Lennart Börjeson

Re: Skia Pipeline

[Michael Paus]

Hi,
what do you want to achieve with Skia? The rendering technique used
by Skia seems to be very similar to what JavaFX does. My impression is
that JavaFX has been very much influenced by it. I'd first do some tests
to see whether the performance is really better or whatever your critera
are.
Keep us updated.
Michael

Am 06.08.18 um 20:39 schrieb Tom Schindl:

Hi,

right and because I'm not really interested in Java 3d (my take on that
is if you need 3d that you'd better use the native techs
OpenGL/Vulkan/Metal/DirectX and integrate them into the FX) I'm not
really worried that 3d is not available in such a render-pipeline.

The first step although would be to write a JNI-Bindings for Skia and/or
using JavaCPP - I guess Panama is too far away to help us ;-) I guess
I'll start digging deeper in the next weeks.

Tom

On 06.08.18 10:12, Matthias Hänel wrote:

Hi Tom,

actually, I analyzed this in the past and it seems to be possible.
We would benefit from the ANGLE implementation underneath.

regards
Matthias

Matthias Hänel
hae...@onexip.com 

onexip GmbH
Am Waldschloesschen 2 | D-01099 Dresden | Germany

http://www.ultramixer.com
http://www.onexip.com



Am 03.08.2018 um 20:44 schrieb Tom Schindl
mailto:tom.schi...@bestsolution.at>>:

Hi,

Has anyone ever explored if it would be possible to implement a
2d-Graphics-Pipeline using Skia?

Tom

--
Tom Schindl, CTO
BestSolution.at  EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

Re: JavaFX SWT and Swing-Interopt

[Michael Paus]

I did the test on a Mac.

MacOS High Sierra
OpenJDK12ea4
OpenJFX11ea20 (SDK)

I just ran the code and repeated the steps given by Tom.
* Bring up the DropDown-List
* Bring up the custom color dialog
* Click somewhere in the JFrame

Michael

Am 31.07.18 um 14:19 schrieb Kevin Rushforth:
I ran the test program on Windows 7 using JDK-11+24 plus my local 
build of openjfx 11, and I can't reproduce the problem. I suspect that 
Prasanta is correct in that this was fixed for FX/Swing interop by 
JDK-8185634 (on the FX side) and JDK-8187803 (on the AWT side). I 
don't know why you and Tom are still seeing this bug. What platform 
are you testing on?


Note that this won't help SWT interop, though. A similar fix might be 
needed there (once we understand why the Swing interop test program 
isn't working for some of you).


-- Kevin

On 7/31/2018 4:45 AM, Michael Paus wrote:

Hi Tom
I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still
see the same baviour which you described.
Michael

Am 31.07.18 um 13:08 schrieb Tom Schindl:

Hi,

I give it a try but from the bug description and discussion I would 
have
assumed it deals with the opposite problems (Opening a Swing-Dialog 
from

an JavaFX-Application who uses Swing-Node).

I also studied the code to see if how you make a JavaFX-Stage having a
different owner but I could only find changes to AWT deal with this.

Anyways I'll try to get it the latest master running. The issue states
that it is fixed in 8u182 but only 8u181 is available and there are no
EA-Builds of Java8 available anymore (Looks like Oracle does not want
people to test fixes for upcoming 8-update anymore)

Tom

On 31.07.18 11:21, Prasanta Sadhukhan wrote:

Hi Tom,

I am not able to see the problem in latest workspace. I believe this
issue is already fixed by JDK-8185634.

Regards
Prasanta
On 7/31/2018 1:16 PM, Tom Schindl wrote:

Hi,

In one of our customers application we have major problems when
embedding JavaFX into SWT (but from my tests the situation is 
equal for

Swing).

In the end all windows (most commonly popup-windows) are affected
because they don't have a parent-window assigned and so they can be
hidden by the window embedding them - if the window opened is 
Modal like

eg the one from ColorPicker the JavaFX UI is also blocked.

To see what I mean just use this snippet below and do the following:
* Bring up the DropDown-List
* Bring up the custom color dialog
* Click somewhere in the JFrame

You notice the following:
* JavaFX Window is moved behind Swing-Window
* JavaFX UI is blocked


package test;

import javax.swing.JFrame;

import javafx.application.Platform;
import javafx.embed.swing.JFXPanel;
import javafx.geometry.Pos;
import javafx.scene.Scene;
import javafx.scene.control.ColorPicker;
import javafx.scene.layout.BorderPane;

public class TestSwingInterop extends JFrame {
  public TestSwingInterop() {
 setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 final JFXPanel fxPanel = new JFXPanel();
  add(fxPanel);
   Platform.runLater(new Runnable() {
  @Override
  public void run() {
  initFX(fxPanel);
  }
  });
 }
  private static void initFX(JFXPanel fxPanel) {
  // This method is invoked on JavaFX thread
  Scene scene = createScene();
  fxPanel.setScene(scene);
  }
  private static Scene createScene() {
 ColorPicker picker = new ColorPicker();
 BorderPane.setAlignment(picker, Pos.TOP_LEFT);
 BorderPane p = new BorderPane(picker);
     return new Scene(p);
 }

 public static void main(String[] args) {
 TestSwingInterop s = new TestSwingInterop();
 s.setBounds(100, 100, 1000, 800);
 s.setVisible(true);
 }
}
I've tested this on Java8 and Java9 but didn't had a chance to run 
it on

the latest master.

The problem is that the newly created JavaFX windows don't have the
Native-Window as their parent but the EmbeddedStage (who is not 
bound to

a native-window handle). It looks like EmbeddedStage has already been
prepared (see getRawHandle() : long) to support something like 
that in

future but com.sun.glass.ui.Window and its subclasses have never been
extend to create a window based on a pure long-pointer.

The only exception and the reason I guess the strategy would work was
used for Applets.

Before diving deeper into this I wanted to get a feedback from people
who know things better: Does the strategy of passing along the window
pointer (eg from SWT, don't know about Swing yet) to Glass and 
using it

as the parent pointer sound like a proper idea?

Tom

Re: JavaFX SWT and Swing-Interopt

[Michael Paus]

Hi Tom
I gave it a try with the latest OpenJDK12ea and OpenJFX11ea and I still
see the same baviour which you described.
Michael

Am 31.07.18 um 13:08 schrieb Tom Schindl:

Hi,

I give it a try but from the bug description and discussion I would have
assumed it deals with the opposite problems (Opening a Swing-Dialog from
an JavaFX-Application who uses Swing-Node).

I also studied the code to see if how you make a JavaFX-Stage having a
different owner but I could only find changes to AWT deal with this.

Anyways I'll try to get it the latest master running. The issue states
that it is fixed in 8u182 but only 8u181 is available and there are no
EA-Builds of Java8 available anymore (Looks like Oracle does not want
people to test fixes for upcoming 8-update anymore)

Tom

On 31.07.18 11:21, Prasanta Sadhukhan wrote:

Hi Tom,

I am not able to see the problem in latest workspace. I believe this
issue is already fixed by JDK-8185634.

Regards
Prasanta
On 7/31/2018 1:16 PM, Tom Schindl wrote:

Hi,

In one of our customers application we have major problems when
embedding JavaFX into SWT (but from my tests the situation is equal for
Swing).

In the end all windows (most commonly popup-windows) are affected
because they don't have a parent-window assigned and so they can be
hidden by the window embedding them - if the window opened is Modal like
eg the one from ColorPicker the JavaFX UI is also blocked.

To see what I mean just use this snippet below and do the following:
* Bring up the DropDown-List
* Bring up the custom color dialog
* Click somewhere in the JFrame

You notice the following:
* JavaFX Window is moved behind Swing-Window
* JavaFX UI is blocked


package test;

import javax.swing.JFrame;

import javafx.application.Platform;
import javafx.embed.swing.JFXPanel;
import javafx.geometry.Pos;
import javafx.scene.Scene;
import javafx.scene.control.ColorPicker;
import javafx.scene.layout.BorderPane;

public class TestSwingInterop extends JFrame {
 
 public TestSwingInterop() {

     setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
     final JFXPanel fxPanel = new JFXPanel();
  add(fxPanel);
   Platform.runLater(new Runnable() {
  @Override
  public void run() {
  initFX(fxPanel);
  }
  });
 }
 
 private static void initFX(JFXPanel fxPanel) {

  // This method is invoked on JavaFX thread
  Scene scene = createScene();
  fxPanel.setScene(scene);
  }
 
 private static Scene createScene() {

     ColorPicker picker = new ColorPicker();
     BorderPane.setAlignment(picker, Pos.TOP_LEFT);
     BorderPane p = new BorderPane(picker);

     return new Scene(p);

 }

 public static void main(String[] args) {
     TestSwingInterop s = new TestSwingInterop();
     s.setBounds(100, 100, 1000, 800);
     s.setVisible(true);
 }
}

I've tested this on Java8 and Java9 but didn't had a chance to run it on
the latest master.

The problem is that the newly created JavaFX windows don't have the
Native-Window as their parent but the EmbeddedStage (who is not bound to
a native-window handle). It looks like EmbeddedStage has already been
prepared (see getRawHandle() : long) to support something like that in
future but com.sun.glass.ui.Window and its subclasses have never been
extend to create a window based on a pure long-pointer.

The only exception and the reason I guess the strategy would work was
used for Applets.

Before diving deeper into this I wanted to get a feedback from people
who know things better: Does the strategy of passing along the window
pointer (eg from SWT, don't know about Swing yet) to Glass and using it
as the parent pointer sound like a proper idea?

Tom

Re: JavaFX 11 snapshots in maven sonatype

[Michael Paus]

Hi Johan,
many thanks for the clarifications.
Please find some more comments inline:

Am 06.07.18 um 14:54 schrieb Johan Vos:

Hi Michael,

Thanks for testing this.

You can avoid downloading all platform jars by specifying the 
javafx.platform with maven:


mvn -Djavafx.platform=mac clean package exec:java
I can confirm that this works as you said if the property is specified 
on the command line

but I am wondering why this does not work if you
set javafx.platform inside the pom.xml as a property like this

    
        mac
        ...
    

or if you specify the classifier explicitly.

    mac

or if you specify the property in the Maven settings.xml file.

In all these three cases Maven still downloads everything.


There is a rationale behind this:
maven would be able to detect the OS and make sure only the platform 
jars related to that OS are downloaded.
But that won't work with gradle. So we have this base pom that, unless 
javafx.platform is specified, will depend on all platforms, which will 
cause gradle to download the correct platform (and the others as well).
Now, for SNAPSHOTs this doesn't work with gradle (see previous mail) 
but that is another issue. For releases, this works with gradle.


I'm very open to suggestions on how to change this.

As for architectures: I would suggest we follow the approach of the 
excellent nd4j project and append the arch if used (see 
https://oss.sonatype.org/content/repositories/snapshots/org/nd4j/nd4j-native/1.0.0-SNAPSHOT/ -- 
it even includes linux-x86_64-avx512)
This looks good to me but shouldn't we then use this architecture 
extension right from the beginning in order to avoid future confusion?


For Eclipse: by setting the {javafx.platform} variable somewhere, it 
will be avoided to download the other platforms.
What would be the right place to do that? As pointed out above the right 
place seems to be very sensitive.

But your error message seems to suggest something else:
 Error: JavaFX runtime components are missing, and are required to  
run this application


That is an issue I brought up somewhere else: 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021977.html
The Java launcher will check if the main class extends 
javafx.application.Application and if that is the case, it will do a 
hard check on the availability of the javafx.graphics module in the 
modulepath. If it can't find that, it will bail with the message 
above. So that is happening.



I was able to temporarily fix this by introducing a separate launcher class.

    package org.projavafx.javafx3d.hello3d;
    public class ShapesLauncher {
        public static void main(String[] args) {
            Shapes.main(args);
        }
    }

But this is a terrible hack.
This doesn't happen when you launch via maven, as maven is launching 
the application inside its own Java process -- hence the main class is 
a maven class, not extending javafx.application.Application.


The solution to this is somehow tell maven or eclipse to use modules. 
With gradle, we have a relative easy way to do this:

run {
    doFirst {
        jvmArgs = [
            '--module-path', classpath.asPath,
            '--add-modules', 'javafx.controls'
        ]
    classpath = sourceSets.main.output
    }
}

I doubt that this will help to set up the class/module path correctly 
when you import an external project into Eclipse.
(unfortunately, we can't use gradle due to that snapshot/platform 
issue, but I tested it with a release extension instead of a snapshot 
extension and then it works).


I would assume maven allows for a similar approach. In general, this 
is an issue not specific to JavaFX: how can you tell maven to use the 
artifacts as modules (e.g. set the correct module-path and add the 
modules).
That is absolutely true and to my opinion we are not doing ourselves a 
favor if we force people into using modules if the most common build 
tools are still not able to fully handle the module system in a 
consistent and correct manner.
The only thing that is JavaFX specific is that the Java launcher will 
exit if ((the main class extends Application) AND (no modules used)).


See 
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-June/021983.html for 
the discussion about this. I'm not 100% what the best approach is 
here. It sounds a bit unfair that you can only NOT use classpath when 
your main class extends javafx.application.Application, but the best 
approach is probably a fix in a maven plugin so that it works with 
modules (might already be there?)
How long are we going to wait for this to happen? My impression is that 
there still is not enough pressure on the tool providers because the 
majority of people is still on Java 8 (or less) and are just ignoring 
the new module system.


- Johan


On Fri, Jul 6, 2018 at 12:51 PM Michael Paus <mailto:m...@jugs.org>> wrote:


Hi,
I tried the examples on my Mac with Maven and with a simple
 mvn clean package 

Re: JavaFX 11 snapshots in maven sonatype

[Michael Paus]

Hi,
I tried the examples on my Mac with Maven and with a simple
    mvn clean package exec:java
on the command line they all compiled and worked out of the box.
Great work! I used OpenJDK 11ea20 for this.

I have a few questions though:

1. I observed that maven downloaded all dependencies for all platforms 
(mac,win,linux)
which does not seem to make much sense. Is this normal or could that be 
prevented somehow?


2. How would the platform concept be extended once we have to also 
distinguish between architectures?

(Linux on x86 vs. Linux on ARM for the Raspi for example)

3. How is this setup supposed to be used in an IDE like Eclipse. I tried 
to import one of the example projects
into Eclipse and Eclipse ended up creating maven dependencies for all 
platforms and not just the Mac.
This has the consequence that you cannot start an example directly in 
Eclipse anymore because it then fails with:
    Error: JavaFX runtime components are missing, and are required to 
run this application
You can launch it via maven but I normally prefer to do it directly 
which is no problem with a normal maven project.


Michael

Am 05.07.18 um 11:03 schrieb Johan Vos:

A first batch of snapshots for the JavaFX 11 modules is now in the maven
sonatype snapshot repository (see
https://oss.sonatype.org/content/repositories/snapshots/org/openjfx/ although
you probably don't want to work with these artifacts directly but use build
tools like maven or gradle to do that)

This is work based on the not-yet-merged PR#83:
https://github.com/javafxports/openjdk-jfx/pull/83

Basically, you need to specify which modules you need (transitive
dependency management will be handled by maven as the modules contain a
pom.xml with the same dependencies as the module-info.java), e.g.



   org.openjfx
   javafx.controls
   11.0.0-SNAPSHOT



I have a few samples that show how you can use those artifacts in your
maven project:
https://github.com/johanvos/javafx11samples (note that this is a temporary
repository)
the topics/javafx3d directory contains a number of standalone samples that
can be executed via
mvn clean install exec:java

Note that some of the samples create a build.gradle as well, but I never
managed to get gradle working with the combination of classifiers and
SNAPSHOT versions (it's actually the reason why I went back from gradle to
maven in other projects -- e.g. dl4j related).

If someone else can somehow fix the build.gradle, that would be great of
course.

Before PR#83 is merged, it would be nice to have a few reports from people
using the snapshots.

- Johan

Re: How to use OpenJFX Early-Access Builds?

[Michael Paus]

How to run an application with the new separate JFX SDK
was discussed in this thread:

http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-May/021819.html

Am 21.06.18 um 18:04 schrieb Thiago Milczarek Sayão:

Hi,

I am trying to use the openjfx early-access builds with openjdk as
described in http://jdk.java.net/openjfx/ (the page says to give
feedback here).

openjdk version "10.0.1" 2018-04-17
OpenJDK Runtime Environment (build 10.0.1+10-Ubuntu-3ubuntu1)
OpenJDK 64-Bit Server VM (build 10.0.1+10-Ubuntu-3ubuntu1, mixed mode)

I have downloaded the openjfx file and unzipped it to:

/home/tsayao/javafx-sdk-11

I am running my jfx application with:

-Djava.library.path=/home/tsayao/javafx-sdk-11/lib -classpath
/home/tsayao/javafx-sdk-11/lib


But i get:

Error: JavaFX runtime components are missing, and are required to run
this application

This is probably known, but I only found answers to old java 8 jfx.

Help is appreciated.

Re: Table Input

[Michael Paus]

But this does not seem to be available for people who already dare to 
use Java9++ :-(

or did I miss something?

Am 20.06.18 um 19:45 schrieb José Pereda:

As Daniel points out, the TableView2 control is a Gluon contribution that
has been merged recently to ControlsFX, but it hasn't been released yet.
Actually there is a pending PR to rename the new control to
FixableTableView.

Regarding commit on focus, it has been implemented in two new table cell
factories, for TextField and ComboBox cells [2].

You can use the snapshot to test it, and of course, you can clone the
repository, there are two samples [1] available.

Jose


[1]
https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx-samples/src/main/java/org/controlsfx/samples/tableview2
[2]
https://bitbucket.org/controlsfx/controlsfx/src/default/controlsfx/src/main/java/org/controlsfx/control/tableview2/cell/TextField2TableCell.java


On Wed, Jun 20, 2018 at 7:06 PM, Daniel Peintner 
wrote:


Hi,


I believe the last time I looked at the TableView2 contribution at

ControlsFX (which can be used as a TableView replacement), commit on

focus

lost was implemented/supported.

Do you have a link?


The PR has been merged but the contribution is not yet available as
ControlsFX release.
Note: I think the credits go to Jose Pereda (Gluon?)

The easist way to test it is using jpro demo [1] where you can find a
TableView2 section.

Having said that, I don't actually know how it is implemented. I just
noticed commit on focus lost support while playing with this demo.

-- Daniel

[1] https://demos.jpro.one/controlsfx.html




 seems to not have it.

---rony


Jonathan Giles  schrieb am Mi., 20. Juni

2018,

10:28:


Yup,

A great regret. I wish it were supported, but it isn't due to

historical

legacy. There are some small ways you can make some progress, e.g. add
focus listeners on the editor node, but they are half solutions at

best.

-- Jonathan
(Tapped on a touch device)

On Wed, 20 Jun 2018, 10:25 AM ,  wrote:


Zitat von Tom Eugelink :


This is a well known and already deeply discussed issue. I'm still
not sure where we are with it, but Jonathan knows I believe.



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

tbd_major ... since nearly 7 years :(( actually, it took 4 years to
get the necessity accepted, then another 2 years playing with
incomplete suggested fixes and then ...

It's a complex problem, requires

a) additional commit/cancel api on the virtual controls to allow
collaborators to cleanly terminate ongoing edits - this part has

still

been debated
b) a major cleanup of cell implementations - this part was under way
(and evolving into the good direction) until Jonathan left


CU, Jeanette


On 19-6-2018 20:53, Ty Young wrote:

On 06/19/2018 10:51 AM, omnip...@gmail.com wrote:


A minor issue in the Table component existed in previous versions

of

JavaFX

when editing in a cell was turned on. Only if the Return key was
pressed was
the data entered into the backing bean. Leaving the cell with Tab

or

by

mouse did not register the change. I thought just when a cell

looses

focus

it should trigger updating the bean. I have not looked at the

recent

builds

but I thought I'd ask if it has come up on anyone's radar. I
noticed it when
I moved from teaching Swing to FX.


Ken Fogel




IIRC, this isn't specific to Table. A spinner with editing enabled
also does this and it breaks events(onKeyTyped does nothing).





--

Re: OpenGL deprecated in OS-X

[Michael Paus]

Hi,
in the light of this announcement it might be a good idea to consider ANGLE

again as a unified rendering platform for JavaFX. Do not try to reinvent 
the wheel

again. The JavaFX community is much too small to always do its own thing.
Relying on a rendering technology which is used by giants like Google 
and Mozilla

is probably a better idea than once again cooking our own soup. Using ANGLE
should also make it possible to finally support WebGL in WebView.
Michael


Am 04.06.18 um 22:51 schrieb Tom Schindl:

Hi,

I don‘t know what the Apple guys are smoking but they just deprecated OpenGL. 
The question is what does this mean for JavaFX.

See https://developer.apple.com/macos/whats-new/

Tom

Von meinem iPhone gesendet

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

[Michael Paus]

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,

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

[Michael Paus]

Hi,

is it possible to get a clear statement on whether it will be possible 
to package a JavaFX application with the new packager in a similar way 
as it is possible right now with the old packager? The texts are a 
little bit vague there. I just don't know whether it is possible to 
create a packager which does not know anything about the GUI framework 
which has been used by an application.


I would also like to express my concerns about the schedule. The next 
Java release (11) will be an LTS release and that means that there will 
not be any packager for all those people who will have to stick with 
this release for a long time. This is a huge step backward for Java 
because there is then no good deployment technology anymore for a long time.


Michael

Am 31.05.18 um 02:11 schrieb Kevin Rushforth:
I just sent an email to the core-libs-dev alias [1] proposing a new 
Packaging Tool as a replacement for javapackager. If you are 
interested in this JEP, you can follow and participate in the 
discussion there.


-- Kevin

[1] 
http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053503.html

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Hi,
a few days ago I was informed in a private e-mail from Bernhard Lutzmann 
how the problem with Eclipse described below can be solved without 
having to provide a module-info.java. The problem in Eclipse is that, 
although the JavaFX jars are explicitly put on the module path in the 
build configuration, this is not copied over to the runtime 
configuration. So each time when you create a new runtime configuration 
you have to go to the dependencies tab in the runtime configuration 
editor and manually remove the JavaFX jars form the classpath and then 
add them one by one to the module path again. I consider this annoying 
behaviour a bug and have thus filed a corresponding bug report.


<https://bugs.eclipse.org/bugs/show_bug.cgi?id=534572>

Michael

Am 09.05.18 um 13:39 schrieb Michael Paus:

Hi,
I investigated the issue of using the standalone JavaFX SDK inside of 
an IDE (Eclipse and IntelliJ) a little bit further. For this purpose I 
used a simple single-class JavaFX program (actually the one which 
Johan used too).


I started with Eclipse, created a simple Java project, added the JFX 
jars to the module path and added the --add-modules command to the 
runtime configuration. The result is: this works at compile time but 
not at runtime.


Then I tried the same with IntelliJ. (I have to admit though that I 
have never seriously used IntelliJ before.) I created the project, 
added the dependencies and configured the runtime. The result is: the 
same error as in Eclipse.


The advantage of IntelliJ though is that it directly shows you the 
command line which was created to launch the application. The problem 
seems to be that IntelliJ (in the same way as Eclipse) just puts the 
JavaFX dependencies on the classpath and not on the module path. The 
only way I found to fix this was to add a module-info.java to the 
project.


module projavafx.helloearthrise.ui {
    requires javafx.graphics;
    requires javafx.controls;
    exports projavafx.helloearthrise.ui;
}

After that you don't need the --add-modules command anymore.

After adding this the setup immediately worked in IntelliJ. In Eclipse 
however the program could now be launched and there was no error or 
warning but the program just hangs and does not show anything on the 
screen. By looking at the generated command line via "ps -ef | grep 
java" I found that Eclipse is adding this option 
"-XstartOnFirstThread" which makes the program hang. There is a switch 
in the Eclipse runtime configuration dialog, which is selected by 
default, and which causes Eclipse to use this option when it thinks it 
is launched with SWT. This is caused by the fact that I have created a 
library (like Nir suggested) into which I put all jars of the JavaFX 
SDK, also the javafx-swt.jar one although it is not needed here. This 
has never been a problem before the split between JDK and JFX. This 
problem can be fixed by either switching off the startOnFirstThread 
option in the runtime configuration or by just not adding the 
javafx-swt.jar.


So, my conclusion for the moment is that you can only use the split 
JDK/JFX in Eclipse/IntelliJ when your main project has a 
module-info.java. This may be a problem if you are not yet ready or 
willing to modularize your application.


If somebody knows a trick to get around this limitation I'd be happy 
to here about it.


Michael


Am 08.05.18 um 14:39 schrieb Michael Paus:

Am 08.05.18 um 14:27 schrieb Tom Schindl:

[...]

3. How do you properly configure an Eclipse (the latest 4.7.3a) 
project

to use this module path. Adding the OpenJDK was no problem but how do
you add the module path for JavaFX? I failed on that.

You just open the Java Build Path-Properties-Page on the project and 
add

the external jars, not?

Tom


That's one of the ways I tried it but ...

1. is that the intended way of doing it? On the command line you just 
specify a single folder.


2. I did this and it resolved all dependencies at compile time but I 
got an exception at runtime


Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.fxml not found

although I also added

--add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media

as VM arguments.

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Hi,
I investigated the issue of using the standalone JavaFX SDK inside of an 
IDE (Eclipse and IntelliJ) a little bit further. For this purpose I used 
a simple single-class JavaFX program (actually the one which Johan used 
too).


I started with Eclipse, created a simple Java project, added the JFX 
jars to the module path and added the --add-modules command to the 
runtime configuration. The result is: this works at compile time but not 
at runtime.


Then I tried the same with IntelliJ. (I have to admit though that I have 
never seriously used IntelliJ before.) I created the project, added the 
dependencies and configured the runtime. The result is: the same error 
as in Eclipse.


The advantage of IntelliJ though is that it directly shows you the 
command line which was created to launch the application. The problem 
seems to be that IntelliJ (in the same way as Eclipse) just puts the 
JavaFX dependencies on the classpath and not on the module path. The 
only way I found to fix this was to add a module-info.java to the project.


module projavafx.helloearthrise.ui {
    requires javafx.graphics;
    requires javafx.controls;
    exports projavafx.helloearthrise.ui;
}

After that you don't need the --add-modules command anymore.

After adding this the setup immediately worked in IntelliJ. In Eclipse 
however the program could now be launched and there was no error or 
warning but the program just hangs and does not show anything on the 
screen. By looking at the generated command line via "ps -ef | grep 
java" I found that Eclipse is adding this option "-XstartOnFirstThread" 
which makes the program hang. There is a switch in the Eclipse runtime 
configuration dialog, which is selected by default, and which causes 
Eclipse to use this option when it thinks it is launched with SWT. This 
is caused by the fact that I have created a library (like Nir suggested) 
into which I put all jars of the JavaFX SDK, also the javafx-swt.jar one 
although it is not needed here. This has never been a problem before the 
split between JDK and JFX. This problem can be fixed by either switching 
off the startOnFirstThread option in the runtime configuration or by 
just not adding the javafx-swt.jar.


So, my conclusion for the moment is that you can only use the split 
JDK/JFX in Eclipse/IntelliJ when your main project has a 
module-info.java. This may be a problem if you are not yet ready or 
willing to modularize your application.


If somebody knows a trick to get around this limitation I'd be happy to 
here about it.


Michael


Am 08.05.18 um 14:39 schrieb Michael Paus:

Am 08.05.18 um 14:27 schrieb Tom Schindl:

[...]


3. How do you properly configure an Eclipse (the latest 4.7.3a) project
to use this module path. Adding the OpenJDK was no problem but how do
you add the module path for JavaFX? I failed on that.


You just open the Java Build Path-Properties-Page on the project and add
the external jars, not?

Tom


That's one of the ways I tried it but ...

1. is that the intended way of doing it? On the command line you just 
specify a single folder.


2. I did this and it resolved all dependencies at compile time but I 
got an exception at runtime


Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.fxml not found

although I also added

--add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media

as VM arguments.

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Am 08.05.18 um 23:55 schrieb Nir Lisker:

Thanks Kevin, that's good to hear.

Michael, adding the external jars as single entries is the simplest 
and most granular way, but you can also define a library from those 
jars and then add that single library to any project:


1. Add Library...
2. User Library
3. User Libraries...
4. New... (give it a name)
5. Add External JARs... (add all the jars)
6. OK/Apply everything.

This creates a single entry in the .classpath:

    path="org.eclipse.jdt.USER_LIBRARY/library_name">


This should be the parallel to specifying a single folder from the 
command line.

I'll give that a try in the morning.


As for the runtime issue, is it finding the other modules?
No, if I do not specify javafx.fxml it complains about the next one. I 
also tried moving all jars to the classpath instead of the module path. 
Again this resolves the compile time dependencies but results in an 
error at runtime. Since Java 9 Eclipse has really become a mess.


- Nir

On Tue, May 8, 2018 at 3:39 PM, Michael Paus <m...@jugs.org 
<mailto:m...@jugs.org>> wrote:


Am 08.05.18 um 14:27 schrieb Tom Schindl:

[...]

3. How do you properly configure an Eclipse (the latest
4.7.3a) project
to use this module path. Adding the OpenJDK was no problem
but how do
you add the module path for JavaFX? I failed on that.

You just open the Java Build Path-Properties-Page on the
project and add
the external jars, not?

Tom


That's one of the ways I tried it but ...

1. is that the intended way of doing it? On the command line you
just specify a single folder.

2. I did this and it resolved all dependencies at compile time but
I got an exception at runtime

Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.fxml not found

although I also added

--add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media

as VM arguments.

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Am 08.05.18 um 14:37 schrieb Paul Ray Russell:

V. pleased to say it's working for me. It builds using our current Maven
build ( which is targeted in Maven at JDK 9)

  
 org.apache.maven.plugins
 maven-compiler-plugin
 3.6.2
 
 1.9
 1.9
 
 -Xlint:unchecked
 
 
 

Trying to set a 1.11 release will give the Maven error:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.6.2:compile
(default-compile) on project KattRunOnTheTide: Fatal error compiling:
error: invalid target release: 1.11 -> [Help 1]

Have you tried using the latest Maven compiler plugin 3.7.0 ?

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Am 08.05.18 um 14:27 schrieb Tom Schindl:

[...]


3. How do you properly configure an Eclipse (the latest 4.7.3a) project
to use this module path. Adding the OpenJDK was no problem but how do
you add the module path for JavaFX? I failed on that.


You just open the Java Build Path-Properties-Page on the project and add
the external jars, not?

Tom


That's one of the ways I tried it but ...

1. is that the intended way of doing it? On the command line you just 
specify a single folder.


2. I did this and it resolved all dependencies at compile time but I got 
an exception at runtime


Error occurred during initialization of boot layer
java.lang.module.FindException: Module javafx.fxml not found

although I also added

--add-modules=javafx.fxml,javafx.controls,javafx.web,javafx.media

as VM arguments.

Re: Announcing EA builds of standalone JavaFX SDK

[Michael Paus]

Hi Kevin,
that's a great achievement. I have a few questions/remarks though:

1. On the announcement page I assume the license agreement should not read
"These binaries are provided under the GNU General Public License 
."

but instead should read
"These early-access, open-source builds are provided under the GNU 
General Public License, version 2, with the Classpath Exception 
."
With or without classpath exception makes a big difference. (The actual 
link is already the same anyway.)


2. I can confirm that a simple program from the command line works 
nicely on my MacBook Pro Retina but I had to add "/lib" to the module 
path to get it working.


3. How do you properly configure an Eclipse (the latest 4.7.3a) project 
to use this module path. Adding the OpenJDK was no problem but how do 
you add the module path for JavaFX? I failed on that.


Michael

Am 08.05.18 um 01:00 schrieb Kevin Rushforth:
I am pleased to announce the first Early Access build of a standalone 
JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an 
OpenJDK 11 EA build.


If your application is in an unnamed module (i.e., your app is on the 
classpath), you can run your application as follows, after unzipping 
the SDK bundle for your platform.


$ java --module-path $PATH_TO_FX/javafx-sdk-11 
--add-modules=javafx.controls,javafx.fxml MyApp


This assumes you don't need media or web. If you do, then add those 
modules, too. Note that since javafx.web "requires transitive 
javafx.controls", you can omit javafx.controls if you add javafx.web.


If you are running a modular application, then you don't need the 
"--add-modules" option.


Note that this is a stepping stone to javafx modules in a repository 
like Maven.


Please test your applications with the SDK and give us feedback.

Thanks.

-- Kevin

[1] http://jdk.java.net/openjfx/

Re: native libs in modules

[Michael Paus]

Am 30.04.18 um 17:29 schrieb Kevin Rushforth:
One thing to note is that unlike the JDK build, all class files for 
Windows, Linux, and Mac are set up to be built (but not shipped) on 
all three platforms, so it might be possible to create a jar file that 
would be the same on all three platforms. I don't know how feasible it 
would be or whether that the right direction to take or not.
If possible, I would like to see a change in this policy to not ship 
certain fragments of the build. Especially I would like to have the 
possibility to use a JavaFX based on OpenGL on Windows too. This would 
make Java truly cross-platform and might offer a lot of possibilities 
for better integration of external graphics tools like for example tools 
based on JOGL. It might also offer the possibility to support WebGL in 
the WebView in the future so that this gap can be closed too. Am I just 
dreaming? What do others think?

Michael

Re: Removal of apps/scenebuilder from OpenJFX repo

[Michael Paus]

How will these changes then be synchronized with the work Gluon is doing 
for the version

distributed by them? Do they work on the same repo?

Am 12.03.18 um 23:25 schrieb Kevin Rushforth:

Hi Florian,

By way of update, after thinking about this for a week (and getting 
some offline feedback), I no longer propose doing this -- at least not 
for the short-mid term. I've retargeted this RFE to tbd_major and 
lowered the priority to P4.


Having said that, we don't have any plans to modify SceneBuilder, but 
will happily accept contributions.


-- Kevin


Florian Brunner wrote:
OK, this still comes a bit as a surprise as the source code has been 
kept in the repo and was not just provided as a ZIP file.


I'm currently working on a tool based on the SceneBuilder Kit. I 
needed to work on the code a bit and was planning to donate the code 
back to OpenJFX once released, as I was under the impression OpenJFX 
would serve as the master / upstream-repo for all SceneBuilder forks. 
I was also under the impression that OpenJFX at least would make sure 
the code works with any new JDK / JavaFX version and hoped it would 
get support for new controls, if any were added to JavaFX.


-Florian

Am Freitag, 2. März 2018, 09:12:15 CET schrieb Kevin Rushforth:
I filed the following JBS isuse to remova the SceneBuilder sources 
from the OpenJFX repo.


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

As mentioned in the Description of that issue, the OpenJFX repo 
contains the source code for a no-longer-maintained version of the 
SceneBuilder tool. Active development on SceneBuilder in the OpenJFX 
repo was stopped over three years ago. Since that time, the only 
changes have been either jigsaw-related changes to keep it buildable 
and runnable, or global changes that happened to touch some of the 
files in apps/scenebuilder.


A fork of SceneBuilder is maintained by Gluon, so anyone wanting to 
get the latest SceneBuilder should go there.


Before I proceed, I wanted to poll the list to see whether anyone 
has a concern with this. I don't plan to take any action for at 
least a week.


-- Kevin