Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Johan Vos]

The packager that works with Java 11 and JavaFX 11 is at

http://download2.gluonhq.com/jpackager/11/jdk.packager-linux.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-osx.ziphttp://download2.gluonhq.com/jpackager/11/jdk.packager-windows.zip

(see
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022500.html
).

However, I highly recommend testing the early access version of jpackage.
That is the way forward for the packager.

- Johan


On Wed, Dec 19, 2018 at 6:36 PM Kevin Rushforth 
wrote:

> I doubt that will work.
>
> We are developing a replacement tool, jpackage [1], which will be part
> of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later
> as a Java runtime. You can download an early access of this tool on
> jdk.java.net [2]. Discussion on jpackage is happening on the
> core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone
> version of javapackager that will work with JDK 11. Johan Vos can
> provide a pointer.
>
> -- Kevin
>
> [1] https://openjdk.java.net/jeps/343
> [2] http://jdk.java.net/jpackage/
> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
>
> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote:
> > I understand the guidance for apps created with OpenJDK 11, is to use
> the javapackager from jdk 10.
> >
> > The old basedir parameter that could be used to direct the packager to
> use a specific runtime is no longer present.
> >
> > Is there any mechanism I’ve missed in order to have the packager from
> jdk10 bundle the 11 runtime plse?
> >
> > Thanks
>
>

RE: RFR: 8214119: Update to 607.1 version of WebKit

[Murali Billa]

Looks fine.
+1
 
One minor observation: 

WCFontImpl.java -> Regarding   log.fine(String.format("str='%s' length=%d", 
str, str.length()));, I see earlier code which followed below format for 
‘length’
 
log.fine(String.format("str='%s' (length=%d)", str, str.length()));
 
Thanks,
Murali

-Original Message-
From: Kevin Rushforth 
Sent: Wednesday, December 19, 2018 7:01 PM
To: Arunprasad Rajkumar ; Murali Billa 
; Johan Vos ; Joeri Sykora 

Cc: Praveen Srivastava ; Victor D'yakov 
; openjfx-dev@openjdk.java.net List 

Subject: Re: RFR: 8214119: Update to 607.1 version of WebKit

Looks good to me.

+1

-- Kevin

On 12/18/2018 10:16 AM, Arunprasad Rajkumar wrote:
> Hi Kevin, Murali, Johan, Joeri,
>
> Please review the following patch which merges GTK WebKit 2.22(607.1) into 
> jfx-dev:
>
> http://cr.openjdk.java.net/~arajkumar/8214119/webrev
>
> Above link has a webrev and a changeset file,
>
> 1. rt-non-native-webkit — Contains changes other than 
> "modules/javafx.web/src/main/native", it will be useful _only_ for review, 
> don’t apply the patch from it.
>
> 2. rt.changeset.gz — Actual changeset file in compressed format which 
> contains all the changes from “rt” directory(including WebKit native 
> changes), uncompress before using it(gunzip rt.changeset.gz) and do the 
> following steps.,
>
> $ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt
> $ cd rt
> $ hg import --no-commit rt.changeset #(from rt.changset.gz)
>
> This changeset requires the following versions of toolchains to build 
> properly,
>
> * MSVC- 2017-15.5.5 or higher on Windows
> * GCC 7.3.0 or higher on Linux
> * Xcode 9.4 or higher on MacOS
>
> Thanks,
> Arun

Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Alan White (Drum Score Editor)]

Thanks. I’ll grab the Glueon ones for now to finish the app migration to 11, ie 
get off jdk 8 before January, and start working with the EA jpackager and 
migrate when suitable. 

Alan

> On 19 Dec 2018, at 13:51, Kevin Rushforth  wrote:
> 
> I doubt that will work.
> 
> We are developing a replacement tool, jpackage [1], which will be part of 
> OpenJDK. It is planned for JDK 13, and will support JDK 11 or later as a Java 
> runtime. You can download an early access of this tool on jdk.java.net [2]. 
> Discussion on jpackage is happening on the core-libs-dev mailing list [3]. 
> Alternatively, Gluon has a standalone version of javapackager that will work 
> with JDK 11. Johan Vos can provide a pointer.
> 
> -- Kevin
> 
> [1] https://openjdk.java.net/jeps/343
> [2] http://jdk.java.net/jpackage/
> [3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev
> 
>> On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote:
>> I understand the guidance for apps created with OpenJDK 11, is to use the 
>> javapackager from jdk 10.
>> 
>> The old basedir parameter that could be used to direct the packager to use a 
>> specific runtime is no longer present.
>> 
>> Is there any mechanism I’ve missed in order to have the packager from jdk10 
>> bundle the 11 runtime plse?
>> 
>> Thanks
> 

Re: Javapackager 10 to bundle OpenJDK 11 runtime

[Kevin Rushforth]

I doubt that will work.

We are developing a replacement tool, jpackage [1], which will be part 
of OpenJDK. It is planned for JDK 13, and will support JDK 11 or later 
as a Java runtime. You can download an early access of this tool on 
jdk.java.net [2]. Discussion on jpackage is happening on the 
core-libs-dev mailing list [3]. Alternatively, Gluon has a standalone 
version of javapackager that will work with JDK 11. Johan Vos can 
provide a pointer.


-- Kevin

[1] https://openjdk.java.net/jeps/343
[2] http://jdk.java.net/jpackage/
[3] http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev

On 12/19/2018 5:28 AM, Alan White (Drum Score Editor) wrote:

I understand the guidance for apps created with OpenJDK 11, is to use the 
javapackager from jdk 10.

The old basedir parameter that could be used to direct the packager to use a 
specific runtime is no longer present.

Is there any mechanism I’ve missed in order to have the packager from jdk10 
bundle the 11 runtime plse?

Thanks

Re: RFR: 8214119: Update to 607.1 version of WebKit

[Kevin Rushforth]

Looks good to me.

+1

-- Kevin

On 12/18/2018 10:16 AM, Arunprasad Rajkumar wrote:

Hi Kevin, Murali, Johan, Joeri,

Please review the following patch which merges GTK WebKit 2.22(607.1) into 
jfx-dev:

http://cr.openjdk.java.net/~arajkumar/8214119/webrev

Above link has a webrev and a changeset file,

1. rt-non-native-webkit — Contains changes other than 
"modules/javafx.web/src/main/native", it will be useful _only_ for review, 
don’t apply the patch from it.

2. rt.changeset.gz — Actual changeset file in compressed format which contains 
all the changes from “rt” directory(including WebKit native changes), 
uncompress before using it(gunzip rt.changeset.gz) and do the following steps.,

$ hg clone http://hg.openjdk.java.net/openjfx/jfx-dev/rt
$ cd rt
$ hg import --no-commit rt.changeset #(from rt.changset.gz)

This changeset requires the following versions of toolchains to build properly,

* MSVC- 2017-15.5.5 or higher on Windows
* GCC 7.3.0 or higher on Linux
* Xcode 9.4 or higher on MacOS

Thanks,
Arun

Javapackager 10 to bundle OpenJDK 11 runtime

[Alan White (Drum Score Editor)]

I understand the guidance for apps created with OpenJDK 11, is to use the 
javapackager from jdk 10. 

The old basedir parameter that could be used to direct the packager to use a 
specific runtime is no longer present. 

Is there any mechanism I’ve missed in order to have the packager from jdk10 
bundle the 11 runtime plse?

Thanks

[12] RFR JDK-8211248: Create manual drag and drop tests for FX / Swing interop

[Prasanta Sadhukhan]

Hi Kevin, All

Please review few manual tests being added to test swingnode/jfxpanel 
DnD feature.


Bug:https://bugs.openjdk.java.net/browse/JDK-8211248

webrev: http://cr.openjdk.java.net/~psadhukhan/fx/8211248/webrev.0/

Regards
Prasanta

Re: Q: Rotated labels, layout and reflow

[Tom Eugelink]

Hey John,

Is VerticalLabel implementation good enough to add to any of the open source 
projects?

Tom


On 19-12-2018 09:55, John Hendrikx wrote:

Update.

I did an attempt to add this functionally to Label itself, by editing 
LabeledSkinBase, and with a few minor modifications (mainly swapping 
width/height variables in a few places), I managed to get this to work.

Creating my own control wasn't really possible as the LabeledSkinBase is using 
text measurement methods that aren't public API so far, and which I would also 
need for a vertical label, so these changes had to be done directly in 
LabeledSkinBase.

However, I found an acceptable work-around as well, extending upon the idea of 
how Group works.  Wrapping a Label into a Pane, swapping all its 
compute*Width/Height methods to call the opposite version, and making sure 
ContentBias is set to Vertical, and you can get a working label that reflows 
correctly while being rendered vertically.

I posted a sample on StackOverflow here: 
https://stackoverflow.com/questions/16921495/javafx-rotate-label-issue/53847417#53847417

--John


On 15/12/2018 12:17, John-Val Rose wrote:

Yes, you are absolutely right John and again I’m sorry that I did not initially 
see the relevance of your question for this list.

I do now and I like your ideas :-)


On 15 Dec 2018, at 22:06, John Hendrikx  wrote:


I asked here because, although not a bug, it may be a good feature to support 
-- and I was looking for confirmation that this really isn't currently 
possible.  It's not a bug because a rotation transform is expected to not 
change the layout bounds.  Making use of Group fixes the layout bounds but 
makes it impossible to do proper dynamic layouts with labels that have been 
rotated 90 degrees.

Questions similar like this one, without good resolutions, show up on forums 
and stackoverflow, and, looking at the bug database, I think even some of the 
graph components part of JavaFX that support rotated labels have similar layout 
problems when texts needs to be cut-off or reflowed in such labels.

I even looked at MigLayout already, and noticed a similar issue reported there 
where rotated labels are not handled properly, probably because the layout 
bounds don't take the rotation into account, which no doubt MigLayout relies on 
to do its thing.

Now, I would love to contribute a fix for this (I contributed some small things 
before), however I think this might be a tough issue to resolve. The way I see 
it, this cannot be solved without Label taking the rotation into account itself 
and providing proper layout bounds -- this is needed because Label decides if 
text reflow needs to occur depending on where it is placed, and this 
information is lost when it is put in a Group.

So I think Label(ed) would need a new Rotate property, which only supports 0, 
90, 180 and 270 degrees, or perhaps an extension to the text direction property 
(left-right, right-left, top-down, down-top), but I think that it serves a 
different purpose that is independent from rotation.

With this extra information, Label can then do the proper layout calculations 
with potential reflow of text and provide correct layout bounds.  The actual 
text rendering would also need to be rotated somehow, and I'm not quite sure 
how that would be accomplished yet for Labels.

All in all, it sounds like quite some effort that would need a good design, 
especially since Label already has a short-cut property to add a Rotate 
transform that cannot be re-used for this, so a new property would have to make 
the difference very clear.

--John


On 15/12/2018 09:18, Tom Eugelink wrote:
It's a bit grey. If this goes towards a bug in the layout, it could be
considered OpenJFX development. It could also go towards a patch,
because instead of using Canvas I would suggest (John) to look at the
HBox and see if you can figure out why it is not doing what you want.
And if that is too complex; write a layout that does this, and
contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also
is the sum of all the extending libraries, not making the suck-it-all-in
mistake Java made.) The layout logic should be similar to when doing it
in Canvas, only reusable.

Also I have found that when rotating is involved, a lot of layouts do
not what you expect them to do. Have you given MigLayout a try? It
sometimes has surprising results (both positive and negative) ;-)





On 15-12-2018 03:14, John-Val Rose wrote:
My feedback would to ask this kind of question on a more appropriate
list or forum.

I believe this list is exclusively to discuss issues related to the
development of OpenJFX itself.

Graciously,

John-Val


On 15 Dec 2018, at 12:50, John Hendrikx  wrote:


(Sent this twice, first message got sent prematurely)

Hi list,

I get the impression that rotation of Labels needs to be something
that is directly supported by Label instead of handling this with a
Rotate transform (setRotate).

I want to achieve som

Re: Q: Rotated labels, layout and reflow

[John Hendrikx]

Update.

I did an attempt to add this functionally to Label itself, by editing 
LabeledSkinBase, and with a few minor modifications (mainly swapping 
width/height variables in a few places), I managed to get this to work.


Creating my own control wasn't really possible as the LabeledSkinBase is 
using text measurement methods that aren't public API so far, and which 
I would also need for a vertical label, so these changes had to be done 
directly in LabeledSkinBase.


However, I found an acceptable work-around as well, extending upon the 
idea of how Group works.  Wrapping a Label into a Pane, swapping all its 
compute*Width/Height methods to call the opposite version, and making 
sure ContentBias is set to Vertical, and you can get a working label 
that reflows correctly while being rendered vertically.


I posted a sample on StackOverflow here: 
https://stackoverflow.com/questions/16921495/javafx-rotate-label-issue/53847417#53847417


--John


On 15/12/2018 12:17, John-Val Rose wrote:

Yes, you are absolutely right John and again I’m sorry that I did not initially 
see the relevance of your question for this list.

I do now and I like your ideas :-)


On 15 Dec 2018, at 22:06, John Hendrikx  wrote:


I asked here because, although not a bug, it may be a good feature to support 
-- and I was looking for confirmation that this really isn't currently 
possible.  It's not a bug because a rotation transform is expected to not 
change the layout bounds.  Making use of Group fixes the layout bounds but 
makes it impossible to do proper dynamic layouts with labels that have been 
rotated 90 degrees.

Questions similar like this one, without good resolutions, show up on forums 
and stackoverflow, and, looking at the bug database, I think even some of the 
graph components part of JavaFX that support rotated labels have similar layout 
problems when texts needs to be cut-off or reflowed in such labels.

I even looked at MigLayout already, and noticed a similar issue reported there 
where rotated labels are not handled properly, probably because the layout 
bounds don't take the rotation into account, which no doubt MigLayout relies on 
to do its thing.

Now, I would love to contribute a fix for this (I contributed some small things 
before), however I think this might be a tough issue to resolve. The way I see 
it, this cannot be solved without Label taking the rotation into account itself 
and providing proper layout bounds -- this is needed because Label decides if 
text reflow needs to occur depending on where it is placed, and this 
information is lost when it is put in a Group.

So I think Label(ed) would need a new Rotate property, which only supports 0, 
90, 180 and 270 degrees, or perhaps an extension to the text direction property 
(left-right, right-left, top-down, down-top), but I think that it serves a 
different purpose that is independent from rotation.

With this extra information, Label can then do the proper layout calculations 
with potential reflow of text and provide correct layout bounds.  The actual 
text rendering would also need to be rotated somehow, and I'm not quite sure 
how that would be accomplished yet for Labels.

All in all, it sounds like quite some effort that would need a good design, 
especially since Label already has a short-cut property to add a Rotate 
transform that cannot be re-used for this, so a new property would have to make 
the difference very clear.

--John


On 15/12/2018 09:18, Tom Eugelink wrote:
It's a bit grey. If this goes towards a bug in the layout, it could be
considered OpenJFX development. It could also go towards a patch,
because instead of using Canvas I would suggest (John) to look at the
HBox and see if you can figure out why it is not doing what you want.
And if that is too complex; write a layout that does this, and
contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also
is the sum of all the extending libraries, not making the suck-it-all-in
mistake Java made.) The layout logic should be similar to when doing it
in Canvas, only reusable.

Also I have found that when rotating is involved, a lot of layouts do
not what you expect them to do. Have you given MigLayout a try? It
sometimes has surprising results (both positive and negative) ;-)





On 15-12-2018 03:14, John-Val Rose wrote:
My feedback would to ask this kind of question on a more appropriate
list or forum.

I believe this list is exclusively to discuss issues related to the
development of OpenJFX itself.

Graciously,

John-Val


On 15 Dec 2018, at 12:50, John Hendrikx  wrote:


(Sent this twice, first message got sent prematurely)

Hi list,

I get the impression that rotation of Labels needs to be something
that is directly supported by Label instead of handling this with a
Rotate transform (setRotate).

I want to achieve something quite trivial if no rotation was
involved, a layout like this, an HBox with 3 labels in it:

 +-HBox--

Review-Request for JDK-8215629

[Michael Ennen]

 Hi,

I'd like to request a review for JDK-8209970 available as a PR on
Github:

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


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


Thanks.

-- 
Michael Ennen