RE: Scenic View updates
I understand Jonathan. I am glad to hear good news, FINAL RELEASE!!!. Good job. Thanks! Diego -Original Message- From: Jonathan Giles [mailto:jonathan.gi...@oracle.com] Sent: Mittwoch, 7. Mai 2014 22:15 To: Cirujano Cuesta, Diego; openjfx-dev@openjdk.java.net Subject: Re: Scenic View updates Scenic View is an app that is developed when time permits, and unfortunately, I haven't had a lot of spare time recently! :-) However, when I get a few hours spare I do manage to work on Scenic View a little bit, and it is getting into shape for a final 8.0 release. I certainly hope that it will be released in the next few weeks, but that might be pushing it. -- Jonathan On 8/05/2014 2:40 a.m., Cirujano Cuesta, Diego wrote: Hi all, I think that I am not the only one that really like the app Scenic View. I saw that since 8.8.13 there aren´t any news and the current Java 8 version is a Developer Preview(4). I didn´t find any info about it in the mailing list. Do you know anything about it? Thanks! Diego --- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted. --- This message is intended for a particular addressee only and may contain business or company secrets. If you have received this email in error, please contact the sender and delete the message immediately. Any use of this email, including saving, publishing, copying, replication or forwarding of the message or the contents is not permitted.
hg: openjfx/8u-dev/rt: RT-36805: [Popup] Popup steals focus, when hiding the popup (regression)
Changeset: 585d0b241f1f Author:Anthony Petrov anthony.pet...@oracle.com Date: 2014-05-08 12:52 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/585d0b241f1f RT-36805: [Popup] Popup steals focus, when hiding the popup (regression) Summary: Don't call requestToFront() on the owner stage if the hiding owned stage is unfocusable Reviewed-by: kcr, snorthov ! modules/graphics/src/main/java/com/sun/javafx/tk/quantum/WindowStage.java
hg: openjfx/8u-dev/rt: RT-37010: [media] Long mp4 files (duration 12hrs) are rejected by the media player.
Changeset: 8c38297db42b Author:anashaty Date: 2014-05-08 17:22 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8c38297db42b RT-37010: [media] Long mp4 files (duration 12hrs) are rejected by the media player. Reviewed-by: stayer, alexander.matv...@oracle.com ! modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/isomp4/qtdemux.c
hg: openjfx/8u-dev/rt: RT-37017: [Build] Don't copy IDE jars to the lib directory if already present
Changeset: 117352966a2e Author:snorthov Date: 2014-05-08 10:42 -0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/117352966a2e RT-37017: [Build] Don't copy IDE jars to the lib directory if already present Summary: Replacing the bytes with exactly the same byes causes IDE recompilation Reviewed by: kcr ! build.gradle
Gradle changes for review RT-36712, RT-37020
jira: https://javafx-jira.kenai.com/browse/RT-36712 webrev: http://cr.openjdk.java.net/~ddhill/RT-36712/ This change provides for an ability to disable native builds for media an webnode, even if they are globally toggled (in my case by the Hudson build engine) This is done with: 69 ARMV5SF.compileWebnodeNative = false; 70 ARMV5SF.compileMediaNative = false; jira: https://javafx-jira.kenai.com/browse/RT-37020 http://cr.openjdk.java.net/~ddhill/RT-37020/ overlaps a bit with the above so must be applied second. This is a general cleanup of the jar filter that we apply to remove extra unneeded platform classes. The cleanup is that we move the basic definitions from the platform properties files back in to the core of gradle. The hope is that it will be easier to maintain in the core of our gradle build. Kevin did mention that a couple of the entries are probably obsolete an not needed (but that is for a different jira). jfxrtJarExcludes should still work if present (and duplicated entries do not cause a problem, but currently should be optional for the base platforms. Tested so far on ARM, Linux and Mac (Kevin will try windows for me), the net result is a two file cleanup for the better in the jars. -- David Hill david.h...@oracle.com Java Embedded Development A hypocrite is a person who--but who isn't? -- Don Marquis (1878 - 1937)
hg: openjfx/8u-dev/rt: RT-36958: [Pagination] Pagination's bullets are oval (instead of circles) in some cases
Changeset: 0f1d33250c1c Author:Felipe Heidrich felipe.heidr...@oracle.com Date: 2014-05-08 08:42 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/0f1d33250c1c RT-36958: [Pagination] Pagination's bullets are oval (instead of circles) in some cases ! apps/toys/Hello/src/main/java/hello/HelloPagination.java ! modules/controls/src/main/java/com/sun/javafx/scene/control/skin/PaginationSkin.java
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: b994378b9ab5 Author:prr Date: 2014-05-08 09:01 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/b994378b9ab5 Fixed RT-35414: Printing] PrintJob.printPage() never returns on Mac OS X Reviewed-by: kcr ! modules/graphics/src/main/java/com/sun/prism/j2d/print/J2DPrinterJob.java Changeset: db68313eea88 Author:kcr Date: 2014-05-08 07:21 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/db68313eea88 RT-33360: Workaround vertical position of content jitters during resize on Linux Summary: Add prism.forceUploadingPainter system property as workaround Reviewed-by: snorthov, ckyang ! modules/graphics/src/main/java/com/sun/prism/GraphicsPipeline.java ! modules/graphics/src/main/java/com/sun/prism/impl/PrismSettings.java
Yet another gradle review - enabling freetype for ARM
jira: RT-36013 https://javafx-jira.kenai.com/browse/RT-36013 webrev: http://cr.openjdk.java.net/~ddhill/RT-36013/ This change enables building Freetype and Pango in a crossbuild. The existing code did not handle the cross build case, leaving it as a todo. I removed one version of the addNative() method, one that listed the applicable platforms, because I could not figure out how to adapt it to the use case we have. Instead, I changed the core addNative method, checking for the required properties needed for the library, and ignoring the addNative request when here is not a matching properties clause. Note that a cross build like Android, we will call addNative for freetype and pango, but as the platform file does no contain a library definition, we will not add a build task. I also added the ability to disable a particular library build in the properties files, adding some additional flexibility, and helping me work around a problem with my soft float toolchain until I can fix that. This change was tested with Linux and ARMV6HF and found to work. ARMV6SF failed to build due to a missing header file, so I have disabled it using ARMV6SF.disablefontFreetype = true With the disable,ARMV6SF was found to work. -- David Hill david.h...@oracle.com Java Embedded Development I have never let my schooling interfere with my education. -- Mark Twain
Re: gradle
On 5/8/14, May 8, 12:31 PM, Johan Vos wrote:
Hi,
We're getting closer to building the JavaFX Android runtime in OpenJFX.
I'm trying to automate all steps in the gradle build files, but my
knowledge is still very limited.
My current bottleneck: I would like to apply retrolambda to all class files
once they are compiled (per module). In my JavaFX Android application, this
is easily done by following the instructions for the retrolambda-gradle
plugin at https://github.com/evant/gradle-retrolambda. I just add apply
plugin: 'retrolambda' and automatically all my class files are converted
from Java 8 to Java 7, with lambda's being replaced.
For some reason, this doesn't work out of the box on the OpenJFX build --
maybe because it's a multiproject, or maybe because the jfxrt.jar is not
created with the jar command?
I currently do the following: unjar the jfxrt.jar after everything is
built, apply retrolambda on the class files, and repackage everything.
Clearly, this is a much dirtier than applying the retrolambda step after
compilation of the class files in each module.
Johan,
defineProperty(JAVAC, cygpath($JDK_HOME/bin/javac${IS_WINDOWS ? '.exe' :
''}))
In theory you could make javac be a shell script that would compile the classes
then convert them with retolambda. Not sure how easy or hard that would be
though, as there is certainly not a 1x1 map to the source files passed to the
output classes.
Another likely candidate would be to perform a pass over the class files just
before we create the jar. I was just in that code tinkering with the filter
mechanism. This would be in:
def jfxrtTask = task(jfxrt$t.capital, type: Jar) {
Not sure how much I like that though, changing all of the class files would
mess with timestamps.
The last suggestion - and the one I like best is using the jar closure/action
|eachFile
http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.bundling.Jar.html#org.gradle.api.tasks.bundling.Jar:eachFile%28org.gradle.api.Action%29(action).
(see
http://www.gradle.org/docs/current/dsl/org.gradle.api.tasks.bundling.Jar.html)
It might be possible/reasonable to call retrolambda on each of the class this
way, hopefully as a filter so you don't touch the originals.
Based on a change I just sent out for review, I would try to define the
action/closure in the platform property file and then conditionally apply it
when present.
Here is the example from my review
http://cr.openjdk.java.net/~ddhill/RT-37020/build.gradle.sdiff.html
|||
2777 if (targetProperties.containsKey('jfxrtJarExcludes')) {
2778 exclude(targetProperties.jfxrtJarExcludes)
2779 }
I think the result would be something like:
if (targetProperties.containsKey('jfxrtJarFilter')) {
eachFile(targetProperties.jfxrtJarFilter)
}
Then the fun would be constructing the filter to filter the contents of the
file using retrolambda
||
Is there someone with sufficient gradle knowledge who can help here?
I've watched a number of gradle tutorials, and while I'm more pleased with
gradle than with maven, the only thing that disturbs me is that
gradle-professionals claim that gradle is extremely easy. Build tools are
NEVER easy for developers :) Some are just a bit easier than others.
Thanks,
- Johan
--
David Hill david.h...@oracle.com
Java Embedded Development
The Internet: where men are men, women are men, and children are FBI agents.
Re: gradle
This is great news. I would go with what you have (the unjaring) for now of course. Are there any changes you are waiting on in OpenJFX? Steve On 2014-05-08 12:31 PM, Johan Vos wrote: Hi, We're getting closer to building the JavaFX Android runtime in OpenJFX. I'm trying to automate all steps in the gradle build files, but my knowledge is still very limited. My current bottleneck: I would like to apply retrolambda to all class files once they are compiled (per module). In my JavaFX Android application, this is easily done by following the instructions for the retrolambda-gradle plugin at https://github.com/evant/gradle-retrolambda. I just add apply plugin: 'retrolambda' and automatically all my class files are converted from Java 8 to Java 7, with lambda's being replaced. For some reason, this doesn't work out of the box on the OpenJFX build -- maybe because it's a multiproject, or maybe because the jfxrt.jar is not created with the jar command? I currently do the following: unjar the jfxrt.jar after everything is built, apply retrolambda on the class files, and repackage everything. Clearly, this is a much dirtier than applying the retrolambda step after compilation of the class files in each module. Is there someone with sufficient gradle knowledge who can help here? I've watched a number of gradle tutorials, and while I'm more pleased with gradle than with maven, the only thing that disturbs me is that gradle-professionals claim that gradle is extremely easy. Build tools are NEVER easy for developers :) Some are just a bit easier than others. Thanks, - Johan
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 6c5f36e9afc5 Author:shemnon Date: 2014-05-08 11:54 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/6c5f36e9afc5 RT-36784: Bad Advice when packaging with an incorrect main jar Summary: 1/ In the existing bundlers, unwrap runtime exceptions wrapping a config exception 2/ When configuring the main jar param from a string, validate the file exists and throw a wrapped config exception if it doesn't ! modules/fxpackager/src/main/java/com/oracle/tools/packager/StandardBundlerParam.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxDebBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/linux/LinuxRpmBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacAppStoreBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDaemonBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacDmgBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/mac/MacPkgBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinAppBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinExeBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinMsiBundler.java ! modules/fxpackager/src/main/java/com/oracle/tools/packager/windows/WinServiceBundler.java ! modules/fxpackager/src/main/resources/com/oracle/tools/packager/StandardBundlerParam.properties Changeset: 294dbfc80092 Author:shemnon Date: 2014-05-08 12:04 -0600 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/294dbfc80092 RT-36784: Bad Advice when packaging with an incorrect main jar Summary: unit test ! modules/fxpackager/src/test/java/com/oracle/tools/packager/BundlersTest.java
[8u] Review Request: RT-36838 - Strange behavior of TreeItem's disclosure arrow // expanded/collapsed state not reflected correctly
This bug was reviewed and approved before, but in looking for a fix for RT-36995, I found some issues with the fix. Namely, that it was possible to have more than one REAPPLY queued up and that it was possible for the REAPPLY happen without a following UPDATE. Rather than roll the fixes for these issues into RT-36995 (especially given than the fix for RT-36995 is dead simple), I reopened RT-36838. http://cr.openjdk.java.net/~dgrieve/RT-36838/webrev.01 https://javafx-jira.kenai.com/browse/RT-36838
[8u] Review Request: RT-36995
Please review https://javafx-jira.kenai.com/browse/RT-36995. The fix is a one-liner, so there is no webrev.
[8u20] RFR: RT-35070 : [Printing] Page dialog can not be opened after print dialog on Linux
https://javafx-jira.kenai.com/browse/RT-35070 http://cr.openjdk.java.net/~prr/rt-35070/ http://cr.openjdk.java.net/%7Eprr/rt-35070/
hg: openjfx/8u-dev/rt: 2 new changesets
Changeset: 8a32fefcbfca Author:hudson Date: 2014-05-07 07:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/8a32fefcbfca Added tag 8u20-b13 for changeset abc855ae09c0 ! .hgtags Changeset: 1a3075ba2181 Author:kcr Date: 2014-05-08 16:56 -0700 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/1a3075ba2181 Automated merge with ssh://jfxsrc.us.oracle.com//javafx/8u/master/jfx/rt
hg: openjfx/2u/dev/rt: 2 new changesets
Changeset: 8098bea31667 Author:hudson Date: 2014-05-07 18:19 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/8098bea31667 Added tag 2.2.60-b19 for changeset 845bff23874e ! .hgtags Changeset: 861ad6a6305c Author:kcr Date: 2014-05-08 16:05 -0700 URL: http://hg.openjdk.java.net/openjfx/2u/dev/rt/rev/861ad6a6305c Automated merge with ssh://jfxsrc.us.oracle.com//javafx/2.2.60/MASTER/jfx/rt
