From florian.kirmaier at gmail.com Tue Sep 3 07:14:03 2019 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Tue, 3 Sep 2019 09:14:03 +0200 Subject: RFR: JDK-8166194 : Poor printing quality Message-ID: Hello, Please review this fix for "Poor printing quality" Ticket: https://github.com/javafxports/openjdk-jfx/issues/379 Pull Request: https://github.com/javafxports/openjdk-jfx/pull/577 Florian Kirmaier From fastegal at swingempire.de Wed Sep 4 12:07:14 2019 From: fastegal at swingempire.de (Jeanette Winzenburg) Date: Wed, 04 Sep 2019 14:07:14 +0200 Subject: RfR: JDK-8092352 - Skip dispatch if there are no handlers/filters Message-ID: <20190904140714.Horde.X5vS-bHX6icOzk-LIwpJMA8@webmail.df.eu> Please review bug fix for JBS: https://bugs.openjdk.java.net/browse/JDK-8092352 openjfx: https://github.com/javafxports/openjdk-jfx/pull/580 Thanks Jeanette From johan.vos at gluonhq.com Tue Sep 10 08:34:41 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Tue, 10 Sep 2019 10:34:41 +0200 Subject: RFR: [JDK-8230775] Release Notes for JavaFX 13 Message-ID: Hi Kevin, Please review https://github.com/javafxports/openjdk-jfx/pull/587 which has the release notes for JavaFX 13 and thus fixes https://github.com/javafxports/openjdk-jfx/issues/586 or https://bugs.openjdk.java.net/browse/JDK-8230775 Thanks, - Johan From mblaesing at doppel-helix.eu Wed Sep 11 19:50:09 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Wed, 11 Sep 2019 21:50:09 +0200 Subject: Release of OpenJFX 13 Message-ID: <1ca6a6cc2f8626cfd8308c0671935c0ed33c53f0.camel@doppel-helix.eu> Hello, I'm a bit confused. According to the release schedule, yesterday OpenJFX 13 should have been released. This also matches the view on https://openjfx.io/ which already holds a download for 13. On maven I find different artifacts: 13 13-ea+14 13-ea+14b both of the ea builds are newer than the 13 release according to the directory listing: https://repo1.maven.org/maven2/org/openjfx/javafx/ It would be great if someone could indicate what happend here? Is my assumption correct, that the tag 13+14 is the base for the maven central build? Apart from this: Thank you for making the release happen! Matthias From joeri.sykora at gluonhq.com Thu Sep 12 07:26:16 2019 From: joeri.sykora at gluonhq.com (Joeri Sykora) Date: Thu, 12 Sep 2019 09:26:16 +0200 Subject: Release of OpenJFX 13 Message-ID: Hi Matthias, in short, version 13 and 13-ea+14b are binary identical. 13-ea+14 was a misconfigured maven publication, that caused the platform dependent artifacts to be missing and should not be used. Longer response: those three versions are maven publications of the exact same build (built from tag 13+14). The dates reflect the time when the artifacts were uploaded to the maven central staging repository and not the time of actual release to maven central release repository. I actually didn't know it would keep the dates of the first publication. We'll keep that in mind for the future releases to republish the final version so there is less confusion. I hope this clarifies things for you. Greetings, Joeri From kevin.rushforth at oracle.com Thu Sep 12 12:46:10 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 12 Sep 2019 05:46:10 -0700 Subject: Proposal: Migrate official jfx repo to GitHub + Skara tooling In-Reply-To: References: Message-ID: Hearing no objection, we plan to switch the official jfx repo from the existing HG openjfx/jfx-dev/rt [1] repo to the GIT openjdk/jfx [2] repo hosted on GitHub on Thursday, September 26, two weeks from today. By way of disclaimer, please be aware that the JEP for moving the JDK repos to GIT [3] is not yet completed, nor has the follow-on JEP to specify the hosting provider for the JDK repos been filed. As such, this should be considered "early access", although I don't anticipate further changes. Here is an overview of the transition timeline. More details, including actions that OpenJFX Contributors need to take, will be communicated after next week's Oracle Code One. Now through Tuesday, September 24 * Follow the existing procedures for code reviews: either use a PR against the javafxports/openjdk-jfx [4] sandbox repo on GitHub or a webrev posted at cr.openjdk.java.net [5] -- in either case send an RFR email * Approved fixes will continue to be pushed to the HG openjfx/jfx-dev/rt repo by a Committer Wednesday, September 25 * The HG openjfx/jfx-dev/rt repo will be made read-only (exact time tbd, probably around noon Pacific time) * The javafxports/openjdk-jfx sandbox repo will be "retired" at this time. Developers will be responsible for migrating open pull requests to openjdk/jfx (I will send out instructions to make this as easy as possible). Thursday, September 26 * The Skara team will turn off the mirroring of HG openjfx/jfx-dev/rt --> GIT openjdk/jfx * I will push a commit to enable jcheck to the openjdk/jfx repo on GitHub * The Skara team will enable the Skara tooling * I will send an announcement that openjdk/jfx is open for pull requests on GitHub Please let me know if there are any questions about the transition. -- Kevin [1] https://hg.openjdk.java.net/openjfx/jfx-dev/rt [2] https://github.com/openjdk/jfx [3] https://openjdk.java.net/jeps/357 [4] https://github.com/javafxports/openjdk-jfx [5] https://cr.openjdk.java.net/ On 8/20/2019 3:14 PM, Kevin Rushforth wrote: > To: OpenJFX Contributors, > > As most of you are aware, Project Skara is moving forward with a > proposed JEP [1] to migrate various OpenJDK projects to git, likely > hosted on GitHub. A read-only git mirror of the HG openjfx/jfx-dev/rt > repo [2] is available on GitHub at openjdk/jfx [3]. Similarly, there > is a read-only mirror of the jdk/jdk repo [4] as well. > > We've been talking with the Skara team about having OpenJFX be one of > the "early adopters" in the git transition. Since a large percentage > of the JavaFX code reviews are already happening on GitHub as pull > requests against the javafxports/openjdk-jfx (sandbox) mirror, the > OpenJFX project would be a natural fit for this. > > For contributors who are not Committers, there won't be many > differences, other than some of the steps will go away (e.g., the > Skara tooling will automate the RFR email). For Committers, there will > be some minor differences, primarily around eliminating steps -- no > more need to merge the pull request into "develop", export the patch, > import it into a Mercurial repo, and push it to the official HG repo. > Instead, you will use the "/integrate" command as a PR comment to > merge the pull request, and then you are done. You will still need to > update JBS, at least initially, to resolve the bug as fixed and add > the URL to the commit, but even that will be automated at some point. > > Developers who are interested in leaning more about the Skara tools > and workflow can find information on the Skara Wiki [5], GitHub > project [6], and mailing list [7]. I note that using the Skara > client-side tools on your desktop is completely optional. 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". > > As a final note, I recommend waiting to create a personal fork of the > openjdk/jfx mirror, since the Skara team is going to re-convert all > openjdk/* mirrors in a couple days [8], and you will just end up > having to delete and refork. > > Comments on this proposal are welcome. > > -- Kevin > > [1] https://openjdk.java.net/jeps/357 > [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt > [3] https://github.com/openjdk/jfx > [4] https://github.com/openjdk/jdk > [5] https://wiki.openjdk.java.net/display/skara > [6] https://github.com/openjdk/skara > [7] https://mail.openjdk.java.net/mailman/listinfo/skara-dev > [8] > https://mail.openjdk.java.net/pipermail/skara-dev/2019-August/000327.html > From mblaesing at doppel-helix.eu Thu Sep 12 18:31:25 2019 From: mblaesing at doppel-helix.eu (Matthias =?ISO-8859-1?Q?Bl=E4sing?=) Date: Thu, 12 Sep 2019 20:31:25 +0200 Subject: Release of OpenJFX 13 In-Reply-To: References: Message-ID: <7b17e7e214b02459217da257461a6cdc1780560d.camel@doppel-helix.eu> Hi Joeri, Am Donnerstag, den 12.09.2019, 09:26 +0200 schrieb Joeri Sykora: > in short, version 13 and 13-ea+14b are binary identical. 13-ea+14 was a > misconfigured maven publication, that caused the platform dependent > artifacts to be missing and should not be used. > > [...] those three versions are maven publications of the exact > same build (built from tag 13+14). [...] thank you, that cleared it and makes sense. Greetings Matthias From swpalmer at gmail.com Fri Sep 13 00:18:06 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Thu, 12 Sep 2019 20:18:06 -0400 Subject: Anyone testing on macOS 10.15 betas? Message-ID: My JavaFX app using JavaFX 13 on OpenJDK 12.0.2 crashes every time I close my main window. I?m not 100% sure if it is a JavaFX issue, but just in case here?s a stack trace. I see libglass.dylib, though it is a few frames away from the crash point.: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff6a488726 __psynch_cvwait + 10 1 libsystem_pthread.dylib 0x00007fff6a549082 _pthread_cond_wait + 701 2 libjvm.dylib 0x000000010ffe32d2 os::PlatformEvent::park() + 126 3 libjvm.dylib 0x000000010ffb95c2 Monitor::ILock(Thread*) + 152 4 libjvm.dylib 0x000000010ffb9a59 Monitor::lock_without_safepoint_check() + 33 5 libjvm.dylib 0x0000000110049e5a SafepointSynchronize::block(JavaThread*) + 324 6 libjvm.dylib 0x00000001100e45f0 JavaThread::check_safepoint_and_suspend_for_native_trans(JavaThread*) + 162 7 libjvm.dylib 0x000000010fdd9d12 jni_NewStringUTF + 142 8 libglass.dylib 0x00000001370c6cf9 +[GlassHelper ClassForName:withEnv:] + 185 9 libglass.dylib 0x00000001370b3d71 -[GlassTouches(hidden) sendJavaTouchEvent:] + 1441 10 libglass.dylib 0x00000001370b3721 listenTouchEvents + 97 11 com.apple.SkyLight 0x00007fff6111fdc0 processEventTapData(void*, unsigned int, unsigned int, unsigned int, unsigned char*, unsigned int) + 631 12 com.apple.SkyLight 0x00007fff61282680 _XPostEventTapData + 277 13 com.apple.SkyLight 0x00007fff6111faeb eventTapMessageHandler(__CFMachPort*, void*, long, void*) + 147 14 com.apple.CoreFoundation 0x00007fff32d9cfd3 __CFMachPortPerform + 250 15 com.apple.CoreFoundation 0x00007fff32d9cecf __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 41 16 com.apple.CoreFoundation 0x00007fff32d9ce1f __CFRunLoopDoSource1 + 541 17 com.apple.CoreFoundation 0x00007fff32d84d7c __CFRunLoopRun + 2612 18 com.apple.CoreFoundation 0x00007fff32d840c3 CFRunLoopRunSpecific + 499 19 com.apple.HIToolbox 0x00007fff31911f2d RunCurrentEventLoopInMode + 292 20 com.apple.HIToolbox 0x00007fff31911c6d ReceiveNextEventCommon + 600 21 com.apple.HIToolbox 0x00007fff319119f7 _BlockUntilNextEventMatchingListInModeWithFilter + 64 22 com.apple.AppKit 0x00007fff2ffbbee4 _DPSNextEvent + 990 23 com.apple.AppKit 0x00007fff2ffbac50 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1352 24 com.apple.AppKit 0x00007fff2ffb5395 -[NSApplication run] + 658 25 libglass.dylib 0x00000001370a7e0c -[GlassApplication runLoop:] + 1932 26 com.apple.Foundation 0x00007fff3553f89a __NSThreadPerformPerform + 254 27 com.apple.CoreFoundation 0x00007fff32da1cd1 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 17 28 com.apple.CoreFoundation 0x00007fff32da1c70 __CFRunLoopDoSource0 + 103 29 com.apple.CoreFoundation 0x00007fff32d85234 __CFRunLoopDoSources0 + 209 30 com.apple.CoreFoundation 0x00007fff32d84840 __CFRunLoopRun + 1272 31 com.apple.CoreFoundation 0x00007fff32d840c3 CFRunLoopRunSpecific + 499 32 libjli.dylib 0x000000010e833444 CreateExecutionEnvironment + 400 33 libjli.dylib 0x000000010e82f5b7 JLI_Launch + 1311 34 java 0x000000010e824ca1 main + 375 35 libdyld.dylib 0x00007fff6a33c2a5 start + 1 Regards, Scott From thevenet.fred at free.fr Fri Sep 13 15:23:46 2019 From: thevenet.fred at free.fr (thevenet.fred at free.fr) Date: Fri, 13 Sep 2019 17:23:46 +0200 (CEST) Subject: Add better handling of NaN Y values to XYCharts Message-ID: <739067162.870525885.1568388226069.JavaMail.zimbra@free.fr> Hi, At the moment, adding samples with a Y value equal to Double.NaN to an XYChart with ValueAxis results in graphs with crippling issues, already well documented: LineChart / AreaChart Series : gap in line / area when using NaN or null as value https://bugs.openjdk.java.net/browse/JDK-8092326 [ValueAxis] AutoRanging: Ignore NaN and null for internal calculation of dataMaxValue and dataMinValue https://bugs.openjdk.java.net/browse/JDK-8091757 Both of these enhancement requests are quite old and in one instance it seems a patch was even proposed, but apparently they kept being postponed for years. I'd be happy to contribute a PR to try and address these issues, but before I start doing anything, I'd like to know if there are any specific reasons, technical or other, for the tickets above to have been postponed like that for so long (especially for JDK-8092326 where code was proposed). Thanks! Frederic Thevenet From kevin.rushforth at oracle.com Fri Sep 13 15:38:45 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 13 Sep 2019 08:38:45 -0700 Subject: Add better handling of NaN Y values to XYCharts In-Reply-To: <739067162.870525885.1568388226069.JavaMail.zimbra@free.fr> References: <739067162.870525885.1568388226069.JavaMail.zimbra@free.fr> Message-ID: Hi Frederic, If you want to contribute a fix for these two issues, along with appropriate unit tests, then please go ahead. I don't know of any technical reasons that would get in the way. I looked at the history of this bug, and there is nothing unusual about it. They are just two of many P4 bugs that never bubbled up high enough in priority to fix. Thanks. -- Kevin On 9/13/2019 8:23 AM, thevenet.fred at free.fr wrote: > Hi, > > At the moment, adding samples with a Y value equal to Double.NaN to an XYChart with ValueAxis results in graphs with crippling issues, already well documented: > > LineChart / AreaChart Series : gap in line / area when using NaN or null as value > https://bugs.openjdk.java.net/browse/JDK-8092326 > > [ValueAxis] AutoRanging: Ignore NaN and null for internal calculation of dataMaxValue and dataMinValue > https://bugs.openjdk.java.net/browse/JDK-8091757 > > Both of these enhancement requests are quite old and in one instance it seems a patch was even proposed, but apparently they kept being postponed for years. > > I'd be happy to contribute a PR to try and address these issues, but before I start doing anything, I'd like to know if there are any specific reasons, technical or other, for the tickets above to have been postponed like that for so long (especially for JDK-8092326 where code was proposed). > > Thanks! > > Frederic Thevenet From andrea.vacondio at gmail.com Mon Sep 16 07:57:05 2019 From: andrea.vacondio at gmail.com (Andrea Vacondio) Date: Mon, 16 Sep 2019 09:57:05 +0200 Subject: Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError Message-ID: 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 From t.rauchhaupt at googlemail.com Mon Sep 16 08:37:47 2019 From: t.rauchhaupt at googlemail.com (Thimo von Rauchhaupt) Date: Mon, 16 Sep 2019 10:37:47 +0200 Subject: Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError In-Reply-To: References: Message-ID: Hello, We had the same issues and fixed it by putting the correct ddl's in the bundled java runtime bin directory (we outpacked them from the javafx distribution). This is the first place, where the ddl's are being searched. Best regards, Thimo Andrea Vacondio schrieb am Mo., 16. Sep. 2019, 09:57: > 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 > > From mp at jugs.org Mon Sep 16 08:58:56 2019 From: mp at jugs.org (Michael Paus) Date: Mon, 16 Sep 2019 10:58:56 +0200 Subject: Exception in thread "WindowsNativeRunloopThread" java.lang.NoSuchMethodError In-Reply-To: References: Message-ID: <339e3de3-e70b-c20a-c36d-e7f98588f1df@jugs.org> 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 From william.h.duquette at jpl.nasa.gov Mon Sep 16 17:40:14 2019 From: william.h.duquette at jpl.nasa.gov (Duquette, Will (US 393E)) Date: Mon, 16 Sep 2019 17:40:14 +0000 Subject: OpenJFX 13, AdoptOpenJDK 12, NetBeans 11 not working Message-ID: <59a065b743454e3587db18098acdb504@jpl.nasa.gov> Howdy. I'm new to this list; I'm a longtime JavaFX 8/NetBeans 8 user. I'm trying to come to grips with OpenJFX. I've installed AdoptOpenJDK 12 and OpenJFX 13, and installed NetBeans 11.1. I've created the JavaFX13 library in NetBeans as described in the OpenJFX getting started guide, and created a simple non-FXML hello world program. It compiles. On the project properties "Run" tab, I've updated the VM options as described in the Getting Started Guide: --module-path /Users/MyUserName/javafx-sdk-13/lib --add-modules javafx.controls (I left the javafx.fxml module off, because I'm not using it.) When I try to run the app, I still get the error Error occurred during initialization of boot layer java.lang.module.FindException: Module javafx.controls not found I've checked and double-checked the module path and the module name. The given lib/ folder contains javafx.controls.jar, along with everything else. But somehow, NetBeans can't find it. Anybody got any ideas? From william.h.duquette at jpl.nasa.gov Mon Sep 16 18:01:24 2019 From: william.h.duquette at jpl.nasa.gov (Duquette, Will (US 393E)) Date: Mon, 16 Sep 2019 18:01:24 +0000 Subject: Can't execute OpenJFX app from command-line on macOS Message-ID: 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); } } From swpalmer at gmail.com Mon Sep 16 18:24:41 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 16 Sep 2019 14:24:41 -0400 Subject: LocalDateTimeStringConverterTest failing Message-ID: I was looking into working on an issue but before I got very far I ran into this test failing. I'm building on macOS. I've tried with OpenJDK 11.0.2 and OpenJDK 12.0.2. gradle :base:test results in: > Task :base:test test.javafx.util.converter.LocalDateTimeStringConverterTest > toString_to_fromString_testRoundtrip[0] FAILED java.time.format.DateTimeParseException: Text '1985-01-12, 12:34 p.m.' could not be parsed, unparsed text found at index 19 at java.base/java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:2049) at java.base/java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1874) at javafx.base/javafx.util.converter.LocalDateTimeStringConverter$LdtConverter.fromString(LocalDateTimeStringConverter.java:208) at javafx.base/javafx.util.converter.LocalDateTimeStringConverter.fromString(LocalDateTimeStringConverter.java:159) at test.javafx.util.converter.LocalDateTimeStringConverterTest.toString_to_fromString_testRoundtrip(LocalDateTimeStringConverterTest.java:131) 5209 tests completed, 1 failed, 27 skipped What am I missing? Regards, Scott From mp at jugs.org Mon Sep 16 18:27:29 2019 From: mp at jugs.org (Michael Paus) Date: Mon, 16 Sep 2019 20:27:29 +0200 Subject: Can't execute OpenJFX app from command-line on macOS In-Reply-To: References: Message-ID: 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); > } > } From william.h.duquette at jpl.nasa.gov Mon Sep 16 19:25:18 2019 From: william.h.duquette at jpl.nasa.gov (Duquette, Will (US 393E)) Date: Mon, 16 Sep 2019 19:25:18 +0000 Subject: [EXTERNAL] Re: Can't execute OpenJFX app from command-line on macOS In-Reply-To: References: Message-ID: <7DA356D7-F8D4-4AD5-A4E6-6B0C6D135328@jpl.nasa.gov> Aha! Good to know, thanks! ?On 9/16/19, 11:28 AM, "openjfx-dev on behalf of Michael Paus" wrote: 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); > } > } From florian.kirmaier at gmail.com Wed Sep 18 11:32:24 2019 From: florian.kirmaier at gmail.com (Florian Kirmaier) Date: Wed, 18 Sep 2019 13:32:24 +0200 Subject: Request for review: JDK-8200224 - Multiple press event when JFXPanel gains focus. Message-ID: Hello, Please review this fix for "Multiple press event when JFXPanel gains focus. Ticket: https://bugs.openjdk.java.net/browse/JDK-8087914 Pull Request: https://github.com/javafxports/openjdk-jfx/pull/591 Florian Kirmaier from JPro From kevin.rushforth at oracle.com Wed Sep 18 18:38:30 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Sep 2019 11:38:30 -0700 Subject: RFR: 8231126: libxslt.md has incorrect version string Message-ID: <9768c5dd-dbbf-a44e-5d8f-8087f2e64116@oracle.com> Guru, Please review the following simple fix to correct the version number string in libxslt.md: https://bugs.openjdk.java.net/browse/JDK-8231126 https://github.com/javafxports/openjdk-jfx/pull/593 Thanks. -- Kevin From swpalmer at gmail.com Wed Sep 18 18:51:58 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 18 Sep 2019 14:51:58 -0400 Subject: Heads up - Building with Gradle 5.6.2 leaves .property files out of jars Message-ID: I know that the supported Gradle version is 5.3, but I decided to try with the version of Gradle I had installed (5.6.2) and things appeared to be working. Until I got a message about QuantumMessagesBundle not found when I tried to run my test app. Eventually I narrowed it down to the build with Gradle 5.6.2 not having the .properties files in the javafx.graphics.jar. I would normally shut up and use ./gradlew like I'm supposed to, but with the recent release of Java 13, and the fact that Gradle 5.3 (and 5.6.2) can't handle the class file version from Java 13, I figured a Gradle upgrade is going to be necessary soon. Cheers, Scott From kevin.rushforth at oracle.com Wed Sep 18 20:44:46 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 18 Sep 2019 13:44:46 -0700 Subject: Heads up - Building with Gradle 5.6.2 leaves .property files out of jars In-Reply-To: References: Message-ID: Hi Scott, Thanks for the heads-up. As you note we will need to upgrade at some point to pick up JDK 13 support, so this is a helpful observation. -- Kevin On 9/18/2019 11:51 AM, Scott Palmer wrote: > I know that the supported Gradle version is 5.3, but I decided to try with > the version of Gradle I had installed (5.6.2) and things appeared to be > working. Until I got a message about QuantumMessagesBundle not found when > I tried to run my test app. Eventually I narrowed it down to the build > with Gradle 5.6.2 not having the .properties files in the > javafx.graphics.jar. > > I would normally shut up and use ./gradlew like I'm supposed to, but with > the recent release of Java 13, and the fact that Gradle 5.3 (and 5.6.2) > can't handle the class file version from Java 13, I figured a Gradle > upgrade is going to be necessary soon. > > > Cheers, > > Scott From swpalmer at gmail.com Thu Sep 19 01:14:00 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Wed, 18 Sep 2019 21:14:00 -0400 Subject: JDK-8130738 TextFlow's tab width is static Message-ID: I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 ). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) TextLayout interface gets a new method: boolean setTabWidth(int spaces) TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; PrismTextLayout implements the new setTabWidth API. I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. What?s the next step? Regards, Scott From sverre.moe at gmail.com Thu Sep 19 08:52:27 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 19 Sep 2019 10:52:27 +0200 Subject: JavaFX 11 Web Module Linux Requires libavcodec-ffmpeg Message-ID: Building an JavaFX application with the jpackage tools adds many additional Linux RPM Requires. Among these are libavcodec56 and libavcodec-ffmpeg56. It is ffmpeg2 that has libavcodec56, but the libavcodec-ffmpeg is nowhere to be found. It does not seem to exist. If building an Java runtime image with the JavaFX 11 Web module, these are among the RPM Requires added to the RPM package built by jpackage. One could actually think it would be the media module that had these requires, but no it doesn't. The jpackage tool does not have any of these Require packages itself. It is getting them from the javafx.web module. If I omit the javafx.web from the java runtime image, these Requires are omitted from the built RPM package: libavcodec-ffmpeg.so.56()(64bit) libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) libavcodec.so.54()(64bit) libavcodec.so.54(LIBAVCODEC_54)(64bit) libavcodec.so.56()(64bit) libavcodec.so.56(LIBAVCODEC_56)(64bit) libavcodec.so.57()(64bit) libavcodec.so.57(LIBAVCODEC_57)(64bit) libavformat-ffmpeg.so.56()(64bit) libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) libavformat.so.54()(64bit) libavformat.so.54(LIBAVFORMAT_54)(64bit) libavformat.so.56()(64bit) libavformat.so.56(LIBAVFORMAT_56)(64bit) libavformat.so.57()(64bit) libavformat.so.57(LIBAVFORMAT_57)(64bit) The problem is since libavcodec-ffmpeg does not exist installing this built package is impossible (or cumbersome at best). It Requires either ffmpeg2 (libavcodec56) or ffmpeg3 (libavcoded57), so most Linux distributions are covered. Even if a Linux distribution has ffmpeg3 it will not install the package because of libavcodec-ffmpeg. What part of the JavaFX Web module requires ffmpeg and libavcodec? I would like to try using this to see if the application works on Linux. Perhaps the libavcodec-ffmpeg is provided by some other package or other named library. /Sverre From kevin.rushforth at oracle.com Thu Sep 19 13:35:52 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Thu, 19 Sep 2019 06:35:52 -0700 Subject: JavaFX 11 Web Module Linux Requires libavcodec-ffmpeg In-Reply-To: References: Message-ID: <8b2440c3-e64b-7598-80a2-cea4fa86e7d5@oracle.com> The dependency on libavcodec56 / libavcodec-ffmpeg56 is almost certainly coming from javafx.media. The javafx.web module depends on? javafx.media, which explains why javafx.web pulls in that dependency. The javafx.media module includes dynamic libraries that are stubs for different versions of libav. If you download the JavaFX SDK, you will see them in the sdk/lib directory with the names libavplugin-NN.so and libavplugin-ffmpeg-NN.so. Alexander can provide more information. -- Kevin On 9/19/2019 1:52 AM, Sverre Moe wrote: > Building an JavaFX application with the jpackage tools adds many additional > Linux RPM Requires. > > Among these are libavcodec56 and libavcodec-ffmpeg56. It is ffmpeg2 that > has libavcodec56, but the libavcodec-ffmpeg is nowhere to be found. It does > not seem to exist. > > If building an Java runtime image with the JavaFX 11 Web module, these are > among the RPM Requires added to the RPM package built by jpackage. One > could actually think it would be the media module that had these requires, > but no it doesn't. > > The jpackage tool does not have any of these Require packages itself. It is > getting them from the javafx.web module. If I omit the javafx.web from the > java runtime image, these Requires are omitted from the built RPM package: > > libavcodec-ffmpeg.so.56()(64bit) > libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) > libavcodec.so.54()(64bit) > libavcodec.so.54(LIBAVCODEC_54)(64bit) > libavcodec.so.56()(64bit) > libavcodec.so.56(LIBAVCODEC_56)(64bit) > libavcodec.so.57()(64bit) > libavcodec.so.57(LIBAVCODEC_57)(64bit) > libavformat-ffmpeg.so.56()(64bit) > libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) > libavformat.so.54()(64bit) > libavformat.so.54(LIBAVFORMAT_54)(64bit) > libavformat.so.56()(64bit) > libavformat.so.56(LIBAVFORMAT_56)(64bit) > libavformat.so.57()(64bit) > libavformat.so.57(LIBAVFORMAT_57)(64bit) > > The problem is since libavcodec-ffmpeg does not exist installing this built > package is impossible (or cumbersome at best). > > It Requires either ffmpeg2 (libavcodec56) or ffmpeg3 (libavcoded57), so > most Linux distributions are covered. Even if a Linux distribution has > ffmpeg3 it will not install the package because of libavcodec-ffmpeg. > > > What part of the JavaFX Web module requires ffmpeg and libavcodec? I would > like to try using this to see if the application works on Linux. Perhaps > the libavcodec-ffmpeg is provided by some other package or other named > library. > > /Sverre From sverre.moe at gmail.com Thu Sep 19 14:02:52 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Thu, 19 Sep 2019 16:02:52 +0200 Subject: JavaFX 11 Web Module Linux Requires libavcodec-ffmpeg In-Reply-To: <8b2440c3-e64b-7598-80a2-cea4fa86e7d5@oracle.com> References: <8b2440c3-e64b-7598-80a2-cea4fa86e7d5@oracle.com> Message-ID: tor. 19. sep. 2019 kl. 15:36 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > The dependency on libavcodec56 / libavcodec-ffmpeg56 is almost certainly > coming from javafx.media. The javafx.web module depends on > javafx.media, which explains why javafx.web pulls in that dependency. > It must have been some error on my side. Removing both the javafx.media and javafx.web will omit the libav* Requires from my RPM package built by jpackage. > The javafx.media module includes dynamic libraries that are stubs for > different versions of libav. If you download the JavaFX SDK, you will > see them in the sdk/lib directory with the names libavplugin-NN.so and > libavplugin-ffmpeg-NN.so. > > Alexander can provide more information. > > The runtime image produced with jlink and the JavaFX jmods do have these so-files present in the lib directory of the runtime image. If they are present there should not be any need to specify them as Requires on the RPM package built by jpackage. Does the problem then lie on the jpackage "scanning" for Linux Package Dependencies? What linux distribution and package where these bundled so-files built from? The libav56 should come from ffmpeg2 package, while libav57 is from ffmpeg3 package, but none of these ffmpeg packages produce a libavcodec-ffmpeg.so. My Linux distribution OpenSUSE, and I have checked with Fedora, do not have the libavcodec-ffmpeg.so. They do however have the libavcodec.so.57 which is among the requires (version 56 and 57). > > On 9/19/2019 1:52 AM, Sverre Moe wrote: > > Building an JavaFX application with the jpackage tools adds many > additional > > Linux RPM Requires. > > > > Among these are libavcodec56 and libavcodec-ffmpeg56. It is ffmpeg2 that > > has libavcodec56, but the libavcodec-ffmpeg is nowhere to be found. It > does > > not seem to exist. > > > > If building an Java runtime image with the JavaFX 11 Web module, these > are > > among the RPM Requires added to the RPM package built by jpackage. One > > could actually think it would be the media module that had these > requires, > > but no it doesn't. > > > > The jpackage tool does not have any of these Require packages itself. It > is > > getting them from the javafx.web module. If I omit the javafx.web from > the > > java runtime image, these Requires are omitted from the built RPM > package: > > > > libavcodec-ffmpeg.so.56()(64bit) > > libavcodec-ffmpeg.so.56(LIBAVCODEC_FFMPEG_56)(64bit) > > libavcodec.so.54()(64bit) > > libavcodec.so.54(LIBAVCODEC_54)(64bit) > > libavcodec.so.56()(64bit) > > libavcodec.so.56(LIBAVCODEC_56)(64bit) > > libavcodec.so.57()(64bit) > > libavcodec.so.57(LIBAVCODEC_57)(64bit) > > libavformat-ffmpeg.so.56()(64bit) > > libavformat-ffmpeg.so.56(LIBAVFORMAT_FFMPEG_56)(64bit) > > libavformat.so.54()(64bit) > > libavformat.so.54(LIBAVFORMAT_54)(64bit) > > libavformat.so.56()(64bit) > > libavformat.so.56(LIBAVFORMAT_56)(64bit) > > libavformat.so.57()(64bit) > > libavformat.so.57(LIBAVFORMAT_57)(64bit) > > > > The problem is since libavcodec-ffmpeg does not exist installing this > built > > package is impossible (or cumbersome at best). > > > > It Requires either ffmpeg2 (libavcodec56) or ffmpeg3 (libavcoded57), so > > most Linux distributions are covered. Even if a Linux distribution has > > ffmpeg3 it will not install the package because of libavcodec-ffmpeg. > > > > > > What part of the JavaFX Web module requires ffmpeg and libavcodec? I > would > > like to try using this to see if the application works on Linux. Perhaps > > the libavcodec-ffmpeg is provided by some other package or other named > > library. > > > > /Sverre > > From kevin.rushforth at oracle.com Fri Sep 20 14:58:28 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Sep 2019 07:58:28 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: Message-ID: Hi Scott, I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. -- Kevin On 9/18/2019 6:14 PM, Scott Palmer wrote: > I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 ). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) > > I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: > TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) > TextLayout interface gets a new method: boolean setTabWidth(int spaces) > TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; > PrismTextLayout implements the new setTabWidth API. > > I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. > > What?s the next step? > > Regards, > > Scott From kevin.rushforth at oracle.com Fri Sep 20 15:00:38 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 20 Sep 2019 08:00:38 -0700 Subject: Proposed schedule for JavaFX 14 Message-ID: Here is the proposed schedule for JavaFX 14. RDP1: Jan 6, 2020 (aka ?feature freeze?) RDP2: Feb 3, 2020 Freeze: Feb 24, 2020 GA: March 10, 2020 We plan to fork a jfx14 stabilization branch at RDP1. The GA date is expected to be one week ahead of JDK 14, matching what we did for 13. Please let Johan or me know if you have any questions. -- Kevin From swpalmer at gmail.com Fri Sep 20 16:57:15 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 20 Sep 2019 12:57:15 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: Message-ID: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> Thanks Kevin. My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. Cheers, Scott > On Sep 20, 2019, at 10:58 AM, Kevin Rushforth wrote: > > Hi Scott, > > I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. > > -- Kevin > > > On 9/18/2019 6:14 PM, Scott Palmer wrote: >> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 ). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >> >> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >> PrismTextLayout implements the new setTabWidth API. >> >> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >> >> What?s the next step? >> >> Regards, >> >> Scott > From tom.schindl at bestsolution.at Fri Sep 20 17:12:03 2019 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Fri, 20 Sep 2019 19:12:03 +0200 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> Message-ID: <7c282d88-c1f1-d8ad-4c81-babc07a3f72e@bestsolution.at> Hi, Well I'm not sure this API is correct on TextFlow, if it is supposed to render complex texts like (MS Word) it rather needs a Tab-Stop API, not? Have we investigated other text-layout controls from other frameworks like Swing, Qt, WPF, ... ? What API do those expose? Tom On 20.09.19 18:57, Scott Palmer wrote: > Thanks Kevin. > > My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. > > If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. > > Cheers, > > Scott > >> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth wrote: >> >> Hi Scott, >> >> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >> >> -- Kevin >> >> >> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 ). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>> >>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>> PrismTextLayout implements the new setTabWidth API. >>> >>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>> >>> What?s the next step? >>> >>> Regards, >>> >>> Scott >> > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck From kevin.rushforth at oracle.com Sat Sep 21 13:57:20 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 21 Sep 2019 06:57:20 -0700 Subject: Proposal: Migrate official jfx repo to GitHub + Skara tooling In-Reply-To: References: Message-ID: I will need a bit more time on my end than I will have in the next couple days, so the planned move to GitHub will be delayed by a little less than a week. The new proposed target is to switch on Wednesday, October 2. As indicated in my earlier message, I will send out details of the transition prior to the switch, including actions that OpenJFX Contributors need to take. I'll send this early next week. The dates listed in the message of 9/12 become: Now through Monday, September 30 : Follow the existing procedures for code reviews, etc. Tuesday, October 1 : HG repo goes read-only, javafxports/openjdk-jfx sandbox repo "retired" Wednesday, October 2 : Switch to GIT repo + Skara tooling -- Kevin On 9/12/2019 5:46 AM, Kevin Rushforth wrote: > Hearing no objection, we plan to switch the official jfx repo from the > existing HG openjfx/jfx-dev/rt [1] repo to the GIT openjdk/jfx [2] > repo hosted on GitHub on Thursday, September 26, two weeks from today. > By way of disclaimer, please be aware that the JEP for moving the JDK > repos to GIT [3] is not yet completed, nor has the follow-on JEP to > specify the hosting provider for the JDK repos been filed. As such, > this should be considered "early access", although I don't anticipate > further changes. > > Here is an overview of the transition timeline. More details, > including actions that OpenJFX Contributors need to take, will be > communicated after next week's Oracle Code One. > > Now through Tuesday, September 24 > * Follow the existing procedures for code reviews: either use a PR > against the javafxports/openjdk-jfx [4] sandbox repo on GitHub or a > webrev posted at cr.openjdk.java.net [5] -- in either case send an RFR > email > * Approved fixes will continue to be pushed to the HG > openjfx/jfx-dev/rt repo by a Committer > > Wednesday, September 25 > * The HG openjfx/jfx-dev/rt repo will be made read-only (exact time > tbd, probably around noon Pacific time) > * The javafxports/openjdk-jfx sandbox repo will be "retired" at this > time. Developers will be responsible for migrating open pull requests > to openjdk/jfx (I will send out instructions to make this as easy as > possible). > > Thursday, September 26 > * The Skara team will turn off the mirroring of HG openjfx/jfx-dev/rt > --> GIT openjdk/jfx > * I will push a commit to enable jcheck to the openjdk/jfx repo on GitHub > * The Skara team will enable the Skara tooling > * I will send an announcement that openjdk/jfx is open for pull > requests on GitHub > > Please let me know if there are any questions about the transition. > > -- Kevin > > [1] https://hg.openjdk.java.net/openjfx/jfx-dev/rt > [2] https://github.com/openjdk/jfx > [3] https://openjdk.java.net/jeps/357 > [4] https://github.com/javafxports/openjdk-jfx > [5] https://cr.openjdk.java.net/ > > > On 8/20/2019 3:14 PM, Kevin Rushforth wrote: >> To: OpenJFX Contributors, >> >> As most of you are aware, Project Skara is moving forward with a >> proposed JEP [1] to migrate various OpenJDK projects to git, likely >> hosted on GitHub. A read-only git mirror of the HG openjfx/jfx-dev/rt >> repo [2] is available on GitHub at openjdk/jfx [3]. Similarly, there >> is a read-only mirror of the jdk/jdk repo [4] as well. >> >> We've been talking with the Skara team about having OpenJFX be one of >> the "early adopters" in the git transition. Since a large percentage >> of the JavaFX code reviews are already happening on GitHub as pull >> requests against the javafxports/openjdk-jfx (sandbox) mirror, the >> OpenJFX project would be a natural fit for this. >> >> For contributors who are not Committers, there won't be many >> differences, other than some of the steps will go away (e.g., the >> Skara tooling will automate the RFR email). For Committers, there >> will be some minor differences, primarily around eliminating steps -- >> no more need to merge the pull request into "develop", export the >> patch, import it into a Mercurial repo, and push it to the official >> HG repo. Instead, you will use the "/integrate" command as a PR >> comment to merge the pull request, and then you are done. You will >> still need to update JBS, at least initially, to resolve the bug as >> fixed and add the URL to the commit, but even that will be automated >> at some point. >> >> Developers who are interested in leaning more about the Skara tools >> and workflow can find information on the Skara Wiki [5], GitHub >> project [6], and mailing list [7]. I note that using the Skara >> client-side tools on your desktop is completely optional. 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". >> >> As a final note, I recommend waiting to create a personal fork of the >> openjdk/jfx mirror, since the Skara team is going to re-convert all >> openjdk/* mirrors in a couple days [8], and you will just end up >> having to delete and refork. >> >> Comments on this proposal are welcome. >> >> -- Kevin >> >> [1] https://openjdk.java.net/jeps/357 >> [2] http://hg.openjdk.java.net/openjfx/jfx-dev/rt >> [3] https://github.com/openjdk/jfx >> [4] https://github.com/openjdk/jdk >> [5] https://wiki.openjdk.java.net/display/skara >> [6] https://github.com/openjdk/skara >> [7] https://mail.openjdk.java.net/mailman/listinfo/skara-dev >> [8] >> https://mail.openjdk.java.net/pipermail/skara-dev/2019-August/000327.html >> > From swpalmer at gmail.com Mon Sep 23 17:18:18 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 23 Sep 2019 13:18:18 -0400 Subject: Use of Hashtable in Prism Message-ID: <3F7F9128-DC0B-46C6-AE6A-498E242AD38B@gmail.com> I just noticed that NetBeans is warning me about use of an ?obsolete collection? in PrismTextLayout.java. Is there a reason this isn?t using HashMap or ConcurrentHashMap ? Scott From philip.race at oracle.com Mon Sep 23 17:32:07 2019 From: philip.race at oracle.com (Philip Race) Date: Mon, 23 Sep 2019 10:32:07 -0700 Subject: Use of Hashtable in Prism In-Reply-To: <3F7F9128-DC0B-46C6-AE6A-498E242AD38B@gmail.com> References: <3F7F9128-DC0B-46C6-AE6A-498E242AD38B@gmail.com> Message-ID: <5D890197.6050703@oracle.com> I am not sure but mutation of the Hashtable only happens from inside a block synchronized on CACHE_SIZE_LOCK. Perhaps this somehow plays into it .. in some way I can't see. But I am told that uncontended locks are quite cheap these days. -phil On 9/23/19, 10:18 AM, Scott Palmer wrote: > I just noticed that NetBeans is warning me about use of an ?obsolete collection? in PrismTextLayout.java. > > Is there a reason this isn?t using HashMap or ConcurrentHashMap ? > > Scott > From kevin.rushforth at oracle.com Mon Sep 23 17:32:20 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 23 Sep 2019 10:32:20 -0700 Subject: Use of Hashtable in Prism In-Reply-To: <3F7F9128-DC0B-46C6-AE6A-498E242AD38B@gmail.com> References: <3F7F9128-DC0B-46C6-AE6A-498E242AD38B@gmail.com> Message-ID: No good reason that I can think of. This seems like something that could be cleaned up if someone wanted to file an issue and contribute a fix. -- Kevin On 9/23/2019 10:18 AM, Scott Palmer wrote: > I just noticed that NetBeans is warning me about use of an ?obsolete collection? in PrismTextLayout.java. > > Is there a reason this isn?t using HashMap or ConcurrentHashMap ? > > Scott > From swpalmer at gmail.com Mon Sep 23 19:57:39 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 23 Sep 2019 15:57:39 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> Message-ID: My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. Regards, Scott > On Sep 20, 2019, at 12:57 PM, Scott Palmer wrote: > > Thanks Kevin. > > My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. > > If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. > > Cheers, > > Scott > >> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth wrote: >> >> Hi Scott, >> >> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >> >> -- Kevin >> >> >> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 ). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>> >>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>> PrismTextLayout implements the new setTabWidth API. >>> >>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>> >>> What?s the next step? >>> >>> Regards, >>> >>> Scott >> > From dlemmermann at gmail.com Tue Sep 24 13:03:54 2019 From: dlemmermann at gmail.com (Dirk Lemmermann) Date: Tue, 24 Sep 2019 15:03:54 +0200 Subject: JavaFX Conference Message-ID: Hi y?all, just a quick notice that we are having a second ?JFX Days? event in Zurich on December 2nd - 4th (jfx-days.com ). We have sessions and workshops and additionally a seminar on using open source software in line with their licensing agreements. Johan Vos will be there and tell us about the OpenJFX roadmap. Bruno Borges will show us how to do CI/CD of JavaFX apps via the Azure pipeline, Michael Hoffer will present his new project ?NativeFX? for native rendering / writable image, etc?. Dirk From kevin.rushforth at oracle.com Tue Sep 24 19:13:49 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Sep 2019 12:13:49 -0700 Subject: RFR: 8231326: Update README and CONTRIBUTING docs for Skara Message-ID: <8fd4ac07-2c19-4575-2bae-831f9223a164@oracle.com> Please review the following to update the top-level README.md and CONTRIBUTING.md files for the switch to Skara: https://bugs.openjdk.java.net/browse/JDK-8231326 https://github.com/javafxports/openjdk-jfx/pull/601 -- Kevin From kevin.rushforth at oracle.com Tue Sep 24 21:10:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Tue, 24 Sep 2019 14:10:50 -0700 Subject: Details on move to Skara-enabled GIT repos Message-ID: ?To: OpenJFX Contributors Here is some additional information on the mechanics of the impending switch to GIT [1]. The high-level overview is as follows. _OVERVIEW_ Before the switch: 1. File an issue to associate your GitHub username with your OpenJDK ID (if you have one) 2. Fork the openjdk/jfx? GitHub repo and create a local clone After the switch: 3. Submitting a pull request to openjdk/jfx _DETAILS_ The following can be done at any time. I recommend you do these before the switch to GIT, since they must be completed before you submit your first pull request to the openjdk/jfx repo: 1. Associate your GitHub username with your OpenJDK ID Everyone with an OpenJDK ID (everyone who is and Author, Committer, or Reviewer in OpenJFX or any other Project) who wants to contribute to OpenJFX needs to file a JBS issue in the Skara project to associate their GitHub username with their OpenJDK ID. This allows the Skara tooling to know what role you have in the Project, and also serves as verification that you have signed the OCA (people without an OpenJDK ID will go through a separate verification step the first time they submit a PR). Click here to file the issue: https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 Use the following as the bug Summary: ??? Associate GitHub user 'MyGitHubUsername' with OpenJDK user 'MyOpenJDKID' And then press "Submit". You don't need to add anything in the Description of the bug. 2. Create a fork of the openjdk/jfx repo A. Go to https://github.com/openjdk/jfx B. Click on the "Fork" button in to the far right of the "openjdk / jfx" repo name C. Create a local clone of your fork on your system See the "Fork a repo" [2] page on GitHub page for more information on creating and managing a fork. IMPORTANT: unless you know exactly what you are doing, do *not* attempt to pull / fetch from a clone of the javafxports/openjdk-jfx repo (or from your personal fork of that repo) into a clone of your newly-created fork of openjdk/jfx. The commit hashes in the javafxports/openjdk-jfx sandbox are not the same as those in the openjdk/jfx repo, so the two repos are "unrelated" to each other. You will have duplicate copies of each of the more than 11,000 commits. I will provide separate instructions for migrating any branches / pull requests that you have. After the switch: 3. Submitting a pull request to openjdk/jfx After we have switched over to the Skara-enable openjdk/jfx GIT repo, every contribution must be done as a pull request against the http://github.com/openjdk/jfx repo (not a webrev posted to cr.openjdk.java.net). You are welcome to use the Skara command line tools to help you with this, but you need not do so. I just sent a PR for review [3] to update the CONTRIBUTING guidelines with the information needed to submit, review, and integrate fixes via a pull request to openjdk/jfx. See the "Submitting your changes via a pull request" section of the updated CONTRIBUTING.md file. As a best practice, please create a separate branch for each contribution. Name the branch with something that is meaningful to you. You can, but need not, include the JBS bug ID in the branch name. I strongly recommend that you not use your master branch for this purpose or it will become confusing. If you use your master branch at all, I recommend that you periodically sync in the upstream master branch (meaning that your master branch never has commits that aren't already in the upstream master). 4. Migrate your open pull requests from javafxports/openjdk-jfx to openjdk/jfx (coming soon) I will send a separate email about migrating existing pull requests against the javafxports/openjdk-jfx sandbox to the official openjdk-jfx repo. Let me know if you have any questions. -- Kevin [1] https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html [2] https://help.github.com/en/articles/fork-a-repo [3] https://github.com/javafxports/openjdk-jfx/pull/601 From johan.vos at gluonhq.com Wed Sep 25 13:57:32 2019 From: johan.vos at gluonhq.com (Johan Vos) Date: Wed, 25 Sep 2019 15:57:32 +0200 Subject: JavaFX 14-ea+1 available Message-ID: Hi, The first EA build for JavaFX 14 is available now from https://gluonhq.com/products/javafx/#ea and from maven central. In the past, I noticed EA-builds are downloaded often, and that's a great thing. I think that without the JavaFX 13 EA-builds and the feedback, the native buffering feature would not have made it into the 13 release. Therefore, I really recommend developers to use JavaFX 14-ea+1 (and later) during daily development. (I do *not* recommend using it in production). Early feedback is crucial in fast release cycles. Thanks, - Johan From kevin.rushforth at oracle.com Wed Sep 25 18:40:51 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2019 11:40:51 -0700 Subject: Details on move to Skara-enabled GIT repos In-Reply-To: References: Message-ID: <5841b1a8-2ae1-3098-41ca-0720076235c0@oracle.com> To: OpenJFX Contributors with open pull requests If you have an open pull request [4] in the javafxports/openjdk-jfx sandbox that isn't merged before the switch (i.e., one that is still open on Tuesday when the HG repo goes read-only), here are some instructions that should help you port your PR to the new openjfx/jfx repo: These instructions presume that you have already created a personal fork of both the existing javafxports/openjdk-jfx sandbox repo and the new openjdk/jfx repo, and that you have locally cloned each of them. It also presumes that you have configured an upstream remote named 'upstream' as suggested here [1]. 1. In your local clone of your personal fork of the old javafxports/openjdk-jfx sandbox repo: The "upstream" remote should point to: https://github.com/javafxports/openjdk-jfx.git cd "MY-JAVAFXPORTS-FORK" git checkout "MYBRANCH" git fetch upstream git merge upstream/develop rm 0*.patch git format-patch upstream/develop..HEAD where "MY-JAVAFXPORTS-FORK" is the local directory into which you have cloned your fork of javafxports/openjdk-jfx, and "MYBRANCJH" is the name of the branch against which you have made the pull request. 2. In your local clone of your personal fork of the new openjdk/jfx repo: The "upstream" remote should point to: https://github.com/openjdk/jfx.git cd "MY-OPENJDK-FORK" git fetch upstream git checkout -b "MYBRANCH" upstream/master git am --keep-cr "MY-JAVAFXPORTS-FORK"/0*.patch where "MY-OPENJDK-FORK" is the local directory into which you have cloned your fork of openjdk/jfx, and "MYBRANCJH" is the name of the branch against which you will make the pull request. Then you can push your branch to your local fork of the new openjdk/jfx repo. Once the repo is open for pull requests (next Wednesday), you can submit a new pull request. -- Kevin [4] https://github.com/javafxports/openjdk-jfx/pulls On 9/24/2019 2:10 PM, Kevin Rushforth wrote: > ?To: OpenJFX Contributors > > Here is some additional information on the mechanics of the impending > switch to GIT [1]. The high-level overview is as follows. > > _OVERVIEW_ > > Before the switch: > > 1. File an issue to associate your GitHub username with your OpenJDK > ID (if you have one) > 2. Fork the openjdk/jfx? GitHub repo and create a local clone > > After the switch: > > 3. Submitting a pull request to openjdk/jfx > > _DETAILS_ > > The following can be done at any time. I recommend you do these before > the switch to GIT, since they must be completed before you submit your > first pull request to the openjdk/jfx repo: > > 1. Associate your GitHub username with your OpenJDK ID > > Everyone with an OpenJDK ID (everyone who is and Author, Committer, or > Reviewer in OpenJFX or any other Project) who wants to contribute to > OpenJFX needs to file a JBS issue in the Skara project to associate > their GitHub username with their OpenJDK ID. This allows the Skara > tooling to know what role you have in the Project, and also serves as > verification that you have signed the OCA (people without an OpenJDK > ID will go through a separate verification step the first time they > submit a PR). > > Click here to file the issue: > https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 > > > Use the following as the bug Summary: > > ??? Associate GitHub user 'MyGitHubUsername' with OpenJDK user > 'MyOpenJDKID' > > And then press "Submit". You don't need to add anything in the > Description of the bug. > > > 2. Create a fork of the openjdk/jfx repo > > A. Go to https://github.com/openjdk/jfx > B. Click on the "Fork" button in to the far right of the "openjdk / > jfx" repo name > C. Create a local clone of your fork on your system > > See the "Fork a repo" [2] page on GitHub page for more information on > creating and managing a fork. > > IMPORTANT: unless you know exactly what you are doing, do *not* > attempt to pull / fetch from a clone of the javafxports/openjdk-jfx > repo (or from your personal fork of that repo) into a clone of your > newly-created fork of openjdk/jfx. The commit hashes in the > javafxports/openjdk-jfx sandbox are not the same as those in the > openjdk/jfx repo, so the two repos are "unrelated" to each other. You > will have duplicate copies of each of the more than 11,000 commits. I > will provide separate instructions for migrating any branches / pull > requests that you have. > > > After the switch: > > 3. Submitting a pull request to openjdk/jfx > > After we have switched over to the Skara-enable openjdk/jfx GIT repo, > every contribution must be done as a pull request against the > http://github.com/openjdk/jfx repo (not a webrev posted to > cr.openjdk.java.net). You are welcome to use the Skara command line > tools to help you with this, but you need not do so. > > I just sent a PR for review [3] to update the CONTRIBUTING guidelines > with the information needed to submit, review, and integrate fixes via > a pull request to openjdk/jfx. See the "Submitting your changes via a > pull request" section of the updated CONTRIBUTING.md file. > > As a best practice, please create a separate branch for each > contribution. Name the branch with something that is meaningful to > you. You can, but need not, include the JBS bug ID in the branch name. > I strongly recommend that you not use your master branch for this > purpose or it will become confusing. If you use your master branch at > all, I recommend that you periodically sync in the upstream master > branch (meaning that your master branch never has commits that aren't > already in the upstream master). > > > 4. Migrate your open pull requests from javafxports/openjdk-jfx to > openjdk/jfx (coming soon) > > I will send a separate email about migrating existing pull requests > against the javafxports/openjdk-jfx sandbox to the official > openjdk-jfx repo. > > > Let me know if you have any questions. > > -- Kevin > > [1] > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html > [2] https://help.github.com/en/articles/fork-a-repo > [3] https://github.com/javafxports/openjdk-jfx/pull/601 > From kevin.rushforth at oracle.com Wed Sep 25 18:45:52 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2019 11:45:52 -0700 Subject: Details on move to Skara-enabled GIT repos In-Reply-To: <5841b1a8-2ae1-3098-41ca-0720076235c0@oracle.com> References: <5841b1a8-2ae1-3098-41ca-0720076235c0@oracle.com> Message-ID: > It also presumes that you have configured an upstream remote named > 'upstream' as suggested here... I forgot to include the link to the GitHub help page for setting up an upstream repo. Here is is: https://help.github.com/en/articles/configuring-a-remote-for-a-fork -- Kevin On 9/25/2019 11:40 AM, Kevin Rushforth wrote: > To: OpenJFX Contributors with open pull requests > > If you have an open pull request [4] in the javafxports/openjdk-jfx > sandbox that isn't merged before the switch (i.e., one that is still > open on Tuesday when the HG repo goes read-only), here are some > instructions that should help you port your PR to the new openjfx/jfx > repo: > > These instructions presume that you have already created a personal > fork of both the existing javafxports/openjdk-jfx sandbox repo and the > new openjdk/jfx repo, and that you have locally cloned each of them. > It also presumes that you have configured an upstream remote named > 'upstream' as suggested here [1]. > > 1. In your local clone of your personal fork of the old > javafxports/openjdk-jfx sandbox repo: > > The "upstream" remote should point to: > https://github.com/javafxports/openjdk-jfx.git > > cd "MY-JAVAFXPORTS-FORK" > git checkout "MYBRANCH" > git fetch upstream > git merge upstream/develop > rm 0*.patch > git format-patch upstream/develop..HEAD > > where "MY-JAVAFXPORTS-FORK" is the local directory into which you have > cloned your fork of javafxports/openjdk-jfx, and "MYBRANCJH" is the > name of the branch against which you have made the pull request. > > 2. In your local clone of your personal fork of the new openjdk/jfx repo: > > The "upstream" remote should point to: https://github.com/openjdk/jfx.git > > cd "MY-OPENJDK-FORK" > git fetch upstream > git checkout -b "MYBRANCH" upstream/master > git am --keep-cr "MY-JAVAFXPORTS-FORK"/0*.patch > > where "MY-OPENJDK-FORK" is the local directory into which you have > cloned your fork of openjdk/jfx, and "MYBRANCJH" is the name of the > branch against which you will make the pull request. > > Then you can push your branch to your local fork of the new > openjdk/jfx repo. Once the repo is open for pull requests (next > Wednesday), you can submit a new pull request. > > -- Kevin > > [4] https://github.com/javafxports/openjdk-jfx/pulls > > > On 9/24/2019 2:10 PM, Kevin Rushforth wrote: >> ?To: OpenJFX Contributors >> >> Here is some additional information on the mechanics of the impending >> switch to GIT [1]. The high-level overview is as follows. >> >> _OVERVIEW_ >> >> Before the switch: >> >> 1. File an issue to associate your GitHub username with your OpenJDK >> ID (if you have one) >> 2. Fork the openjdk/jfx? GitHub repo and create a local clone >> >> After the switch: >> >> 3. Submitting a pull request to openjdk/jfx >> >> _DETAILS_ >> >> The following can be done at any time. I recommend you do these >> before the switch to GIT, since they must be completed before you >> submit your first pull request to the openjdk/jfx repo: >> >> 1. Associate your GitHub username with your OpenJDK ID >> >> Everyone with an OpenJDK ID (everyone who is and Author, Committer, >> or Reviewer in OpenJFX or any other Project) who wants to contribute >> to OpenJFX needs to file a JBS issue in the Skara project to >> associate their GitHub username with their OpenJDK ID. This allows >> the Skara tooling to know what role you have in the Project, and also >> serves as verification that you have signed the OCA (people without >> an OpenJDK ID will go through a separate verification step the first >> time they submit a PR). >> >> Click here to file the issue: >> https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 >> >> >> Use the following as the bug Summary: >> >> ??? Associate GitHub user 'MyGitHubUsername' with OpenJDK user >> 'MyOpenJDKID' >> >> And then press "Submit". You don't need to add anything in the >> Description of the bug. >> >> >> 2. Create a fork of the openjdk/jfx repo >> >> A. Go to https://github.com/openjdk/jfx >> B. Click on the "Fork" button in to the far right of the "openjdk / >> jfx" repo name >> C. Create a local clone of your fork on your system >> >> See the "Fork a repo" [2] page on GitHub page for more information on >> creating and managing a fork. >> >> IMPORTANT: unless you know exactly what you are doing, do *not* >> attempt to pull / fetch from a clone of the javafxports/openjdk-jfx >> repo (or from your personal fork of that repo) into a clone of your >> newly-created fork of openjdk/jfx. The commit hashes in the >> javafxports/openjdk-jfx sandbox are not the same as those in the >> openjdk/jfx repo, so the two repos are "unrelated" to each other. You >> will have duplicate copies of each of the more than 11,000 commits. I >> will provide separate instructions for migrating any branches / pull >> requests that you have. >> >> >> After the switch: >> >> 3. Submitting a pull request to openjdk/jfx >> >> After we have switched over to the Skara-enable openjdk/jfx GIT repo, >> every contribution must be done as a pull request against the >> http://github.com/openjdk/jfx repo (not a webrev posted to >> cr.openjdk.java.net). You are welcome to use the Skara command line >> tools to help you with this, but you need not do so. >> >> I just sent a PR for review [3] to update the CONTRIBUTING guidelines >> with the information needed to submit, review, and integrate fixes >> via a pull request to openjdk/jfx. See the "Submitting your changes >> via a pull request" section of the updated CONTRIBUTING.md file. >> >> As a best practice, please create a separate branch for each >> contribution. Name the branch with something that is meaningful to >> you. You can, but need not, include the JBS bug ID in the branch >> name. I strongly recommend that you not use your master branch for >> this purpose or it will become confusing. If you use your master >> branch at all, I recommend that you periodically sync in the upstream >> master branch (meaning that your master branch never has commits that >> aren't already in the upstream master). >> >> >> 4. Migrate your open pull requests from javafxports/openjdk-jfx to >> openjdk/jfx (coming soon) >> >> I will send a separate email about migrating existing pull requests >> against the javafxports/openjdk-jfx sandbox to the official >> openjdk-jfx repo. >> >> >> Let me know if you have any questions. >> >> -- Kevin >> >> [1] >> https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html >> [2] https://help.github.com/en/articles/fork-a-repo >> [3] https://github.com/javafxports/openjdk-jfx/pull/601 >> > From kevin.rushforth at oracle.com Wed Sep 25 19:20:52 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Wed, 25 Sep 2019 12:20:52 -0700 Subject: RFR: 8231310: Add .jcheck/conf to jfx git repo Message-ID: <5b33e67d-9719-75cf-0a1d-206228f445b9@oracle.com> Please review the following to add the .jcheck/conf file to configure jcheck for the Skara tools: https://bugs.openjdk.java.net/browse/JDK-8231310 https://github.com/javafxports/openjdk-jfx/pull/595 Thanks. -- Kevin From ebresie at gmail.com Sat Sep 28 13:12:06 2019 From: ebresie at gmail.com (Eric Bresie) Date: Sat, 28 Sep 2019 08:12:06 -0500 Subject: Details on move to Skara-enabled GIT repos In-Reply-To: d78f8306-1f14-8848-ecf2-57d86ca33efe@oracle.com References: d1945993-12cf-0b8b-6223-54c9fd15dcd1@oracle.com 5841b1a8-2ae1-3098-41ca-0720076235c0@oracle.com 5841b1a8-2ae1-3098-41ca-0720076235c0@oracle.com Message-ID: <1fdf5720-cea2-4f74-8163-95685b021b96@Erics-iPhone-X> I was wondering, does any of this information need to be added into any of the existing documentation? Eric Bresie Ebresie at gmail.com > On September 25, 2019 at 1:45:52 PM CDT, Kevin Rushforth wrote: > > > It also presumes that you have configured an upstream remote named > > 'upstream' as suggested here... > > I forgot to include the link to the GitHub help page for setting up an > upstream repo. Here is is: > > https://help.github.com/en/articles/configuring-a-remote-for-a-fork > > -- Kevin > > > On 9/25/2019 11:40 AM, Kevin Rushforth wrote: > > To: OpenJFX Contributors with open pull requests > > > > If you have an open pull request [4] in the javafxports/openjdk-jfx > > sandbox that isn't merged before the switch (i.e., one that is still > > open on Tuesday when the HG repo goes read-only), here are some > > instructions that should help you port your PR to the new openjfx/jfx > > repo: > > > > These instructions presume that you have already created a personal > > fork of both the existing javafxports/openjdk-jfx sandbox repo and the > > new openjdk/jfx repo, and that you have locally cloned each of them. > > It also presumes that you have configured an upstream remote named > > 'upstream' as suggested here [1]. > > > > 1. In your local clone of your personal fork of the old > > javafxports/openjdk-jfx sandbox repo: > > > > The "upstream" remote should point to: > > https://github.com/javafxports/openjdk-jfx.git > > > > cd "MY-JAVAFXPORTS-FORK" > > git checkout "MYBRANCH" > > git fetch upstream > > git merge upstream/develop > > rm 0*.patch > > git format-patch upstream/develop..HEAD > > > > where "MY-JAVAFXPORTS-FORK" is the local directory into which you have > > cloned your fork of javafxports/openjdk-jfx, and "MYBRANCJH" is the > > name of the branch against which you have made the pull request. > > > > 2. In your local clone of your personal fork of the new openjdk/jfx repo: > > > > The "upstream" remote should point to: https://github.com/openjdk/jfx.git > > > > cd "MY-OPENJDK-FORK" > > git fetch upstream > > git checkout -b "MYBRANCH" upstream/master > > git am --keep-cr "MY-JAVAFXPORTS-FORK"/0*.patch > > > > where "MY-OPENJDK-FORK" is the local directory into which you have > > cloned your fork of openjdk/jfx, and "MYBRANCJH" is the name of the > > branch against which you will make the pull request. > > > > Then you can push your branch to your local fork of the new > > openjdk/jfx repo. Once the repo is open for pull requests (next > > Wednesday), you can submit a new pull request. > > > > -- Kevin > > > > [4] https://github.com/javafxports/openjdk-jfx/pulls > > > > > > On 9/24/2019 2:10 PM, Kevin Rushforth wrote: > > > To: OpenJFX Contributors > > > > > > Here is some additional information on the mechanics of the impending > > > switch to GIT [1]. The high-level overview is as follows. > > > > > > _OVERVIEW_ > > > > > > Before the switch: > > > > > > 1. File an issue to associate your GitHub username with your OpenJDK > > > ID (if you have one) > > > 2. Fork the openjdk/jfx GitHub repo and create a local clone > > > > > > After the switch: > > > > > > 3. Submitting a pull request to openjdk/jfx > > > > > > _DETAILS_ > > > > > > The following can be done at any time. I recommend you do these > > > before the switch to GIT, since they must be completed before you > > > submit your first pull request to the openjdk/jfx repo: > > > > > > 1. Associate your GitHub username with your OpenJDK ID > > > > > > Everyone with an OpenJDK ID (everyone who is and Author, Committer, > > > or Reviewer in OpenJFX or any other Project) who wants to contribute > > > to OpenJFX needs to file a JBS issue in the Skara project to > > > associate their GitHub username with their OpenJDK ID. This allows > > > the Skara tooling to know what role you have in the Project, and also > > > serves as verification that you have signed the OCA (people without > > > an OpenJDK ID will go through a separate verification step the first > > > time they submit a PR). > > > > > > Click here to file the issue: > > > https://bugs.openjdk.java.net/secure/CreateIssue.jspa?pid=11300&issuetype=1 > > > > > > > > > Use the following as the bug Summary: > > > > > > Associate GitHub user 'MyGitHubUsername' with OpenJDK user > > > 'MyOpenJDKID' > > > > > > And then press "Submit". You don't need to add anything in the > > > Description of the bug. > > > > > > > > > 2. Create a fork of the openjdk/jfx repo > > > > > > A. Go to https://github.com/openjdk/jfx > > > B. Click on the "Fork" button in to the far right of the "openjdk / > > > jfx" repo name > > > C. Create a local clone of your fork on your system > > > > > > See the "Fork a repo" [2] page on GitHub page for more information on > > > creating and managing a fork. > > > > > > IMPORTANT: unless you know exactly what you are doing, do *not* > > > attempt to pull / fetch from a clone of the javafxports/openjdk-jfx > > > repo (or from your personal fork of that repo) into a clone of your > > > newly-created fork of openjdk/jfx. The commit hashes in the > > > javafxports/openjdk-jfx sandbox are not the same as those in the > > > openjdk/jfx repo, so the two repos are "unrelated" to each other. You > > > will have duplicate copies of each of the more than 11,000 commits. I > > > will provide separate instructions for migrating any branches / pull > > > requests that you have. > > > > > > > > > After the switch: > > > > > > 3. Submitting a pull request to openjdk/jfx > > > > > > After we have switched over to the Skara-enable openjdk/jfx GIT repo, > > > every contribution must be done as a pull request against the > > > http://github.com/openjdk/jfx repo (not a webrev posted to > > > cr.openjdk.java.net). You are welcome to use the Skara command line > > > tools to help you with this, but you need not do so. > > > > > > I just sent a PR for review [3] to update the CONTRIBUTING guidelines > > > with the information needed to submit, review, and integrate fixes > > > via a pull request to openjdk/jfx. See the "Submitting your changes > > > via a pull request" section of the updated CONTRIBUTING.md file. > > > > > > As a best practice, please create a separate branch for each > > > contribution. Name the branch with something that is meaningful to > > > you. You can, but need not, include the JBS bug ID in the branch > > > name. I strongly recommend that you not use your master branch for > > > this purpose or it will become confusing. If you use your master > > > branch at all, I recommend that you periodically sync in the upstream > > > master branch (meaning that your master branch never has commits that > > > aren't already in the upstream master). > > > > > > > > > 4. Migrate your open pull requests from javafxports/openjdk-jfx to > > > openjdk/jfx (coming soon) > > > > > > I will send a separate email about migrating existing pull requests > > > against the javafxports/openjdk-jfx sandbox to the official > > > openjdk-jfx repo. > > > > > > > > > Let me know if you have any questions. > > > > > > -- Kevin > > > > > > [1] > > > https://mail.openjdk.java.net/pipermail/openjfx-dev/2019-September/023551.html > > > [2] https://help.github.com/en/articles/fork-a-repo > > > [3] https://github.com/javafxports/openjdk-jfx/pull/601 > > > > > > From kevin.rushforth at oracle.com Sat Sep 28 14:45:44 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Sat, 28 Sep 2019 07:45:44 -0700 Subject: Details on move to Skara-enabled GIT repos In-Reply-To: <1fdf5720-cea2-4f74-8163-95685b021b96@Erics-iPhone-X> References: <1fdf5720-cea2-4f74-8163-95685b021b96@Erics-iPhone-X> Message-ID: On 9/28/2019 6:12 AM, Eric Bresie wrote: > I was wondering, does any of this information need to be added into any of the existing documentation? Some of it already made it into the updated CONTRIBUTING.md [1] docs, but I'm sure it can be improved. Most of what I sent is transitional information aimed at existing contributors who have outstanding pull requests or who have an OpenJDK ID (i.e., Author, Committer, or Reviewer). That shouldn't go into the docs, since it will be outdated soon. Maybe the following could be added to the CONTRIBUTING docs? >>>> ... >>>> >>>> As a best practice, please create a separate branch for each >>>> contribution. Name the branch with something that is meaningful to >>>> you. You can, but need not, include the JBS bug ID in the branch >>>> name. I strongly recommend that you not use your master branch for >>>> this purpose or it will become confusing. If you use your master >>>> branch at all, I recommend that you periodically sync in the upstream >>>> master branch (meaning that your master branch never has commits that >>>> aren't already in the upstream master). >>>> If there are other things that could be done to make it more clear, we could also do that. -- Kevin [1] https://github.com/openjdk/jfx/blob/master/CONTRIBUTING.md From sverre.moe at gmail.com Mon Sep 30 10:08:40 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 30 Sep 2019 12:08:40 +0200 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: I have created an issue for this on GitHub. https://github.com/javafxports/openjdk-jfx/issues/607 /Sverre man. 26. aug. 2019 kl. 20:03 skrev Sverre Moe : > I think I have found a bug/regression with Java 11 regarding TreeTableView. > This has worked fine on JavaFX 8, but is messed up with JavaFX 11. > 1) The arrow button is on the text > 2) No text indentation levels: Each row (no matter the level) is at the > left edge of the TreeTableView. > > I can file an issue at GitHub if this is a real bug/regression. I just > wanted to check first here. > > TreeTableColumn column = new > TreeTableColumn<>("Column"); > column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>(new > OurDataObjectLabel(param.getValue().getValue()))); > > We are using Label here so we can set StyleClass based on some information > in the OurDataObject. > > class OurDataObject { > private String name; > public String getName() { return name; } > } > > class AlsoOurDataObject extends OurDataObject { > public boolean isSomething() { ... } > } > > class OurDataObjectLabel extends Label() { > public OurDataObjectLabel(OurDataObject ourDataObject) { > setText(ourDataObject.getName()); > if (ourDataObject instanceof AlsoOurDataObject) { > if (((AlsoOurDataObject) ourDataObject).isSomething()) { > getStyleClass().add("style"); > } > } > } > } > > A workaround was to use OurDataObject for both types in the > TreeTableColumn, create a CellFactory to do what has been done in > OurDataObjectLabel and in addition to the CellValueFactory. > > Code Example for reproducing the problem: > This is using a String instead of an Object as the data model for > simplicity. > I have attached a screenshot that illustrates this problem. Made with the > example code below. > > import javafx.application.Application; > import javafx.beans.property.ReadOnlyObjectWrapper; > import javafx.scene.Scene; > import javafx.scene.control.TreeItem; > import javafx.scene.control.TreeTableColumn; > import javafx.scene.control.TreeTableView; > import javafx.scene.layout.StackPane; > import javafx.scene.text.Text; > import javafx.stage.Stage; > > public class App extends Application { > > public static void main(String[] args) { > App.launch(args); > } > > @Override > public void start(Stage stage) throws Exception { > StackPane root = new StackPane(); > > TreeTableView treeTableView = new TreeTableView<>(); > treeTableView.setShowRoot(false); > root.getChildren().add(treeTableView); > > TreeTableColumn column = new > TreeTableColumn<>("Column"); > column.setPrefWidth(200); > treeTableView.getColumns().add(column); > > column.setCellValueFactory(param -> new ReadOnlyObjectWrapper<>( > new Text(param.getValue().getValue()))); > > TreeItem rootItem = new TreeItem<>(""); > treeTableView.setRoot(rootItem); > > TreeItem item1 = new TreeItem<>("LEVEL1"); > item1.setExpanded(true); > rootItem.getChildren().add(item1); > > TreeItem item2 = new TreeItem<>("LEVEL2"); > item2.setExpanded(true); > item1.getChildren().add(item2); > > TreeItem item3 = new TreeItem<>("LEVEL2_1"); > item3.setExpanded(true); > item2.getChildren().add(item3); > > Scene scene = new Scene(root, 250, 150); > > stage.setTitle("JavaFX11"); > stage.setScene(scene); > stage.show(); > } > } > > > /Sverre > > From kevin.rushforth at oracle.com Mon Sep 30 12:45:03 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2019 05:45:03 -0700 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: Hi Sverre, Thanks for bringing this to our attention. Can you please file a bug at bugreport.java.com [1]? This seems like a good time to remind everyone that JBS [2] is our bug tracking system. This GitHub issue tracker is not actively tracked or managed. The official GitHub repos in the openjdk organization will not have the issue tracker enabled, which should help avoid this confusion. -- Kevin [1] https://bugreport.java.com/ [2] https://bugs.openjdk.java.net/ [3] https://github.com/openjdk/ On 9/30/2019 3:08 AM, Sverre Moe wrote: > I have created an issue for this on GitHub. > https://github.com/javafxports/openjdk-jfx/issues/607 > > /Sverre > From mp at jugs.org Mon Sep 30 13:04:06 2019 From: mp at jugs.org (Michael Paus) Date: Mon, 30 Sep 2019 15:04:06 +0200 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: 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 From kevin.rushforth at oracle.com Mon Sep 30 13:41:05 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2019 06:41:05 -0700 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: <7132e692-46b8-eeae-608b-e05c82c48253@oracle.com> This mailing list would be the place for discussion of issues. If there is additional relevant information that comes out of the discussion, someone with an OpenJDK ID can add it to the bug report. One problem with an enabled issue tracker, which is what we have now in the javafxports/openjdk-jfx sandbox, is that it gives the illusion that it is being used to track issues. It isn't and never has been. Both the README and CONTRIBUTING docs state that "while the issue tracker in this Github project can be a convenient place to file an issue (either a bug or an enhancement request), the official bug database for OpenJFX is JBS.", but we still get people asking about the status of an "issue" filed there. -- Kevin On 9/30/2019 6:04 AM, Michael Paus wrote: > 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 > From nlisker at gmail.com Mon Sep 30 13:42:05 2019 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 Sep 2019 16:42:05 +0300 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: Hi Michael, doesn't this again exclude all external developers from discussing issues > with other developers? > The mailing lists were established as the place where these discussions should take place, and anyone can write there. The situation with the javafxports/openjfx repo was a problematic, at least for me. People would discuss issues there and submit a fix to them only for the mailing list to be notified when it was ready for review. Anyone who does not keep constant track of the GitHub issues would not have a chance to say anything until that point. I have, by chance, caught several discussions there on topics relevant to me that I would have have liked to know about. It could also easily cause two people to work on the same issue in two different channels because many who used GitHub were not even registered to the mailing lists until the official fix submission. To my opinion disabling the issue tracker defeats the whole purpose of > using GitHub at all > GitHub's main strengths for contributors are the ease of code reviewing (inline comments etc.) compared to discussions on JIRA (JBS), and the ease of submitting a fix - PR with automated tests - compared to the current Webrev with manual tests. Having another issue tracker was actually a disadvantage. - Nir On Mon, Sep 30, 2019 at 4:05 PM Michael Paus wrote: > 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 > > From sverre.moe at gmail.com Mon Sep 30 13:59:29 2019 From: sverre.moe at gmail.com (Sverre Moe) Date: Mon, 30 Sep 2019 15:59:29 +0200 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: I filed it on bugreport.java.com > We will review your report and have assigned it an internal review ID : 9062382. /Sverre man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth < kevin.rushforth at oracle.com>: > Hi Sverre, > > Thanks for bringing this to our attention. Can you please file a bug at > bugreport.java.com [1]? > > This seems like a good time to remind everyone that JBS [2] is our bug > tracking system. This GitHub issue tracker is not actively tracked or > managed. The official GitHub repos in the openjdk organization will not > have the issue tracker enabled, which should help avoid this confusion. > > -- Kevin > > [1] https://bugreport.java.com/ > [2] https://bugs.openjdk.java.net/ > [3] https://github.com/openjdk/ > > On 9/30/2019 3:08 AM, Sverre Moe wrote: > > I have created an issue for this on GitHub. > > https://github.com/javafxports/openjdk-jfx/issues/607 > > > > /Sverre > > > > From m4gw4s at gmail.com Mon Sep 30 14:23:38 2019 From: m4gw4s at gmail.com (=?UTF-8?B?TWFnb3PDoW55aSDDgXJww6Fk?=) Date: Mon, 30 Sep 2019 15:23:38 +0100 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: <77d657e0-a7fc-7f14-512b-f7391fba6925@gmail.com> I cannot find the bug by searching for the number either as keyword or bug id. Not having a public issue tracker is kinda defeats being open source. On 9/30/19 2:59 PM, Sverre Moe wrote: > I filed it on bugreport.java.com >> We will review your report and have assigned it an internal review ID : > 9062382. > > /Sverre > > man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth < > kevin.rushforth at oracle.com>: > >> Hi Sverre, >> >> Thanks for bringing this to our attention. Can you please file a bug at >> bugreport.java.com [1]? >> >> This seems like a good time to remind everyone that JBS [2] is our bug >> tracking system. This GitHub issue tracker is not actively tracked or >> managed. The official GitHub repos in the openjdk organization will not >> have the issue tracker enabled, which should help avoid this confusion. >> >> -- Kevin >> >> [1] https://bugreport.java.com/ >> [2] https://bugs.openjdk.java.net/ >> [3] https://github.com/openjdk/ >> >> On 9/30/2019 3:08 AM, Sverre Moe wrote: >>> I have created an issue for this on GitHub. >>> https://github.com/javafxports/openjdk-jfx/issues/607 >>> >>> /Sverre >>> >> From nlisker at gmail.com Mon Sep 30 14:29:50 2019 From: nlisker at gmail.com (Nir Lisker) Date: Mon, 30 Sep 2019 17:29:50 +0300 Subject: Bug in TreeTableView rendering In-Reply-To: <77d657e0-a7fc-7f14-512b-f7391fba6925@gmail.com> References: <77d657e0-a7fc-7f14-512b-f7391fba6925@gmail.com> Message-ID: > > I cannot find the bug by searching for the number either as keyword or bug > id. > The bug was still not moved to the public issue tracker (JBS). It first goes through a behind-the-scenes review to filter irrelevant and security issues (and maybe other things). That number is clearly stated as "internal review ID". On Mon, Sep 30, 2019 at 5:24 PM Magos?nyi ?rp?d wrote: > > I cannot find the bug by searching for the number either as keyword or > bug id. > > Not having a public issue tracker is kinda defeats being open source. > > > On 9/30/19 2:59 PM, Sverre Moe wrote: > > I filed it on bugreport.java.com > >> We will review your report and have assigned it an internal review ID : > > 9062382. > > > > /Sverre > > > > man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth < > > kevin.rushforth at oracle.com>: > > > >> Hi Sverre, > >> > >> Thanks for bringing this to our attention. Can you please file a bug at > >> bugreport.java.com [1]? > >> > >> This seems like a good time to remind everyone that JBS [2] is our bug > >> tracking system. This GitHub issue tracker is not actively tracked or > >> managed. The official GitHub repos in the openjdk organization will not > >> have the issue tracker enabled, which should help avoid this confusion. > >> > >> -- Kevin > >> > >> [1] https://bugreport.java.com/ > >> [2] https://bugs.openjdk.java.net/ > >> [3] https://github.com/openjdk/ > >> > >> On 9/30/2019 3:08 AM, Sverre Moe wrote: > >>> I have created an issue for this on GitHub. > >>> https://github.com/javafxports/openjdk-jfx/issues/607 > >>> > >>> /Sverre > >>> > >> > > From kevin.rushforth at oracle.com Mon Sep 30 15:12:03 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2019 08:12:03 -0700 Subject: Bug in TreeTableView rendering In-Reply-To: References: <77d657e0-a7fc-7f14-512b-f7391fba6925@gmail.com> Message-ID: <63aad9c3-f975-db9d-abfa-bbf2d261d20f@oracle.com> Bugs filed at bugreport.java.com will become public once reviewed, which usually takes a day or so. I can (and will for the ones filed today) speed up the process if needed. -- Kevin On 9/30/2019 7:29 AM, Nir Lisker wrote: >> I cannot find the bug by searching for the number either as keyword or bug >> id. >> > The bug was still not moved to the public issue tracker (JBS). It first > goes through a behind-the-scenes review to filter irrelevant and security > issues (and maybe other things). That number is clearly stated as "internal > review ID". > > On Mon, Sep 30, 2019 at 5:24 PM Magos?nyi ?rp?d wrote: > >> I cannot find the bug by searching for the number either as keyword or >> bug id. >> >> Not having a public issue tracker is kinda defeats being open source. >> >> >> On 9/30/19 2:59 PM, Sverre Moe wrote: >>> I filed it on bugreport.java.com >>>> We will review your report and have assigned it an internal review ID : >>> 9062382. >>> >>> /Sverre >>> >>> man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth < >>> kevin.rushforth at oracle.com>: >>> >>>> Hi Sverre, >>>> >>>> Thanks for bringing this to our attention. Can you please file a bug at >>>> bugreport.java.com [1]? >>>> >>>> This seems like a good time to remind everyone that JBS [2] is our bug >>>> tracking system. This GitHub issue tracker is not actively tracked or >>>> managed. The official GitHub repos in the openjdk organization will not >>>> have the issue tracker enabled, which should help avoid this confusion. >>>> >>>> -- Kevin >>>> >>>> [1] https://bugreport.java.com/ >>>> [2] https://bugs.openjdk.java.net/ >>>> [3] https://github.com/openjdk/ >>>> >>>> On 9/30/2019 3:08 AM, Sverre Moe wrote: >>>>> I have created an issue for this on GitHub. >>>>> https://github.com/javafxports/openjdk-jfx/issues/607 >>>>> >>>>> /Sverre >>>>> >> From kevin.rushforth at oracle.com Mon Sep 30 15:15:19 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2019 08:15:19 -0700 Subject: Bug in TreeTableView rendering In-Reply-To: References: Message-ID: Thanks. -- Kevin On 9/30/2019 6:59 AM, Sverre Moe wrote: > I filed it on bugreport.java.com > > We will review your report and have assigned it an internal review > ID : 9062382. > > /Sverre > > man. 30. sep. 2019 kl. 14:49 skrev Kevin Rushforth > >: > > Hi Sverre, > > Thanks for bringing this to our attention. Can you please file a > bug at > bugreport.java.com [1]? > > This seems like a good time to remind everyone that JBS [2] is our > bug > tracking system. This GitHub issue tracker is not actively tracked or > managed. The official GitHub repos in the openjdk organization > will not > have the issue tracker enabled, which should help avoid this > confusion. > > -- Kevin > > [1] https://bugreport.java.com/ > [2] https://bugs.openjdk.java.net/ > [3] https://github.com/openjdk/ > > On 9/30/2019 3:08 AM, Sverre Moe wrote: > > I have created an issue for this on GitHub. > > https://github.com/javafxports/openjdk-jfx/issues/607 > > > > /Sverre > > > From swpalmer at gmail.com Mon Sep 30 16:48:52 2019 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 30 Sep 2019 12:48:52 -0400 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> Message-ID: <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> Okay, current work relocated to a clone of the new official Git repo. My initial implementation is here: https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f I would submit it as a pull request but that seems premature since there hasn?t been any real discussion of challenges I?ve overlooked. All I have are the famous last words, ?It works for me.? I saw in the archives a concern about tab width vs tab stops. For some reason I didn?t get the email. Anyway, I don?t think arbitrary tab stop positions, at different intervals that is, are what was asked for. That certainly would require a significantly different implementation. Would love to keep some momentum going on this before I become busy with other things and won?t have time for it. Scott > On Sep 23, 2019, at 3:57 PM, Scott Palmer wrote: > > My current work is here https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 > > While writing a unit test I realized that the StubToolkit isn?t really running the Prism layout code, so I?m not sure how that gets tested. I made it work with StubTextLayout for now. > > Regards, > > Scott > > >> On Sep 20, 2019, at 12:57 PM, Scott Palmer > wrote: >> >> Thanks Kevin. >> >> My current implementation appears to be working for TextFlow and Text, with the TextFlow overriding the tabWidth of the child Text nodes. This seems to work out naturally from the way TextFlow overrides the TextLayout instance used by the Text node. >> >> If there are tricky corner-cases that I?m missing, I guess figuring out all the cases it will need to handle is part of this discussion. It didn?t seem to be that challenging so far, so perhaps I am missing something (hopefully not). I wrote a small test app to visually see that things were working as I expected. I have not yet written the unit tests. >> >> Cheers, >> >> Scott >> >>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth > wrote: >>> >>> Hi Scott, >>> >>> I'm sure Phil will have more comments on this. While the API seems simple enough on the surface, I suspect that this will be a challenging feature to implement correctly for all of the cases it will need to handle. It would need careful review and testing as well. My only comment on the API itself is that if we do accept this feature, it should probably go on both Text and TextFlow, and be one of the attributes of Text that is ignored / overridden when a Text node is in a TextFlow. >>> >>> -- Kevin >>> >>> >>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>> I would like to implement this feature, being able to adjust the tab size in a TextFlow or Text node (JDK-8130738 >). It involves new public API, so I want to start a discussion about it here. (My motivation is that RichTextFX suggests an entirely unacceptable workaround of substituting actual spaces when the tab character is typed and cites the lack of this API.) >>>> >>>> I?ve already jumped the gun and taken a crack at an implementation. It is currently incomplete as I was just poking around to see if it was going to be easy enough to not take up too much of my time. It boils down to: >>>> TextFlow and Text get a new property for tab width, an integer representing the number of spaces taken by a tab. (The value is only used to initialize the tab width for the TextLayout when needed.) >>>> TextLayout interface gets a new method: boolean setTabWidth(int spaces) >>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>> PrismTextLayout implements the new setTabWidth API. >>>> >>>> I?m not sure that the Text node needs this new property. I figured it would be rarely used on that class, so I had implemented it via an added property in the private TextAttributes class. Maybe it isn?t needed at all. >>>> >>>> What?s the next step? >>>> >>>> Regards, >>>> >>>> Scott >>> >> > From kevin.rushforth at oracle.com Mon Sep 30 23:21:50 2019 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Mon, 30 Sep 2019 16:21:50 -0700 Subject: JDK-8130738 TextFlow's tab width is static In-Reply-To: <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> References: <86CCCD49-4559-45D4-A0E5-D202CA20AE2F@gmail.com> <817E37FA-61F8-4AB5-B554-D6E447CCFFEF@gmail.com> Message-ID: Hi Scott, Thanks for the update. I haven't had much time lately between the Skara switch and trying to keep up with jpackage changes... The next step is, as you note, to continue discussion any issues around the API, including whether and how it might interact with a rich text editor that wanted to have a list of variable tab stops (like many word processors use). On this point, I wouldn't imagine wanting to implement variable tab stops in TextFlow, but I would want to think through how a feature layered on top of TextFlow would override the fixed tab width that TextFlow has; since we have this problem today, I don't think this is making it worse, but some discussion on that point would be good. Once there is general buy-in on adding this feature, and on the approach, it would be good to review the API, although that's quite simple. Finally, I would want Phil's input before approving the API. -- Kevin On 9/30/2019 9:48 AM, Scott Palmer wrote: > Okay, current work relocated to a clone of the new official Git repo. > My initial implementation is here: > https://github.com/swpalmer/jfx/commit/cc6193451bf8a693093f3ded5dcbe47af2fcbe8f > > > I would submit it as a pull request but that seems premature since > there hasn?t been any real discussion of challenges I?ve overlooked. > ?All I have are the famous last words, ?It works for me.? > > I saw in the archives a concern about tab width vs tab stops. For some > reason I didn?t get the email. ?Anyway, I don?t think arbitrary tab > stop positions, at different intervals that is, are what was asked > for. ?That certainly would require a significantly different > implementation. > > Would love to keep some momentum going on this before I become busy > with other things and won?t have time for it. > > Scott > >> On Sep 23, 2019, at 3:57 PM, Scott Palmer > > wrote: >> >> My current work is here >> https://github.com/javafxports/openjdk-jfx/compare/develop...swpalmer:jdk-8130738?expand=1 >> >> >> While writing a unit test I realized that the StubToolkit isn?t >> really running the Prism layout code, so I?m not sure how that gets >> tested. ?I made it work with StubTextLayout for now. >> >> Regards, >> >> Scott >> >> >>> On Sep 20, 2019, at 12:57 PM, Scott Palmer >> > wrote: >>> >>> Thanks Kevin. >>> >>> My current implementation appears to be working for TextFlow and >>> Text, with the TextFlow overriding the tabWidth of the child Text >>> nodes. ?This seems to work out naturally from the way TextFlow >>> overrides the TextLayout instance used by the Text node. >>> >>> If there are tricky corner-cases that I?m missing, I guess figuring >>> out all the cases it will need to handle is part of this discussion. >>> ?It didn?t seem to be that challenging so far, so perhaps I am >>> missing something (hopefully not). ?I wrote a small test app to >>> visually see that things were working as I expected. ?I have not yet >>> written the unit tests. >>> >>> Cheers, >>> >>> Scott >>> >>>> On Sep 20, 2019, at 10:58 AM, Kevin Rushforth >>>> > wrote: >>>> >>>> Hi Scott, >>>> >>>> I'm sure Phil will have more comments on this. While the API seems >>>> simple enough on the surface, I suspect that this will be a >>>> challenging feature to implement correctly for all of the cases it >>>> will need to handle. It would need careful review and testing as >>>> well. My only comment on the API itself is that if we do accept >>>> this feature, it should probably go on both Text and TextFlow, and >>>> be one of the attributes of Text that is ignored / overridden when >>>> a Text node is in a TextFlow. >>>> >>>> -- Kevin >>>> >>>> >>>> On 9/18/2019 6:14 PM, Scott Palmer wrote: >>>>> I would like to implement this feature, being able to adjust the >>>>> tab size in a TextFlow or Text node (JDK-8130738 >>>>> ). ?It involves >>>>> new public API, so I want to start a discussion about it here. >>>>> ?(My motivation is that RichTextFX suggests an entirely >>>>> unacceptable workaround of substituting actual spaces when the tab >>>>> character is typed and cites the lack of this API.) >>>>> >>>>> I?ve already jumped the gun and taken a crack at an >>>>> implementation. ?It is currently incomplete as I was just poking >>>>> around to see if it was going to be easy enough to not take up too >>>>> much of my time. ?It boils down to: >>>>> TextFlow and Text get a new property for tab width, an integer >>>>> representing the number of spaces taken by a tab. (The value is >>>>> only used to initialize the tab width for the TextLayout when needed.) >>>>> TextLayout interface gets a new method: ?boolean setTabWidth(int >>>>> spaces) >>>>> TextLayout gets a new constant: DEFAULT_TAB_WIDTH = 8; >>>>> PrismTextLayout implements the new setTabWidth API. >>>>> >>>>> I?m not sure that the Text node needs this new property. ?I >>>>> figured it would be rarely used on that class, so I had >>>>> implemented it via an added property in the private TextAttributes >>>>> class. ?Maybe it isn?t needed at all. >>>>> >>>>> What?s the next step? >>>>> >>>>> Regards, >>>>> >>>>> Scott >>>> >>> >> >