Re: [12] RFR: JDK-8209966: Update minimum boot JDK to 11

On 9/21/18 5:27 PM, Kevin Rushforth wrote: Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8209966 https://github.com/javafxports/openjdk-jfx/pull/174 This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11. -- Kevin Is requiring the

Re: BUG: TableView's setMouseTransparent method does not make mouse transparent

On 9/19/18 10:27 AM, Kevin Rushforth wrote: JavaFX does not use exclusive full-screen mode. It simulates full screen by using an undecorated window that is exactly the size of the screen. This means that pop-ups, such as those used by ComboBox and content menus, will continue to work (they

[12] RFR: JDK-8210092: Remove old javafx.swing implementation

Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8210092 https://github.com/javafxports/openjdk-jfx/pull/207 https://github.com/javafxports/openjdk-jfx/pull/207/files This will remove the old JDK-10-based implementation of FX / Swing interop and cleanup the build

[12] RFR: JDK-8210093: Build FX class files with -source 11 and -target 11

Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8210093 https://github.com/javafxports/openjdk-jfx/pull/208 This will start building the FX class files with "-source 11" and "-target 11" for JavaFX 12. It is dependent on JDK-8209966. -- Kevin

[12] RFR: JDK-8209966: Update minimum boot JDK to 11

Please review the following on GitHub: https://bugs.openjdk.java.net/browse/JDK-8209966 https://github.com/javafxports/openjdk-jfx/pull/174 This will bump the minimum boot JDK needed to build JavaFX 12 to JDK 11. -- Kevin

Re: Talk about OPENJFX's future

That seems like a very workable model to me. -- Kevin On 9/21/2018 12:56 PM, Johan Vos wrote: Adding to #2: what we try to do with gluon is increasing adoption, allow free development and usage, while still getting revenues to fund the development. All builds created for the latest version of

Re: Talk about OPENJFX's future

Adding to #2: what we try to do with gluon is increasing adoption, allow free development and usage, while still getting revenues to fund the development. All builds created for the latest version of JavaFX are free to use (GPL + CPE) for private and commercial usage. With the Gluon JavaFX

Re: Talk about OPENJFX's future

I note that this isn't really the right forum for discussing the cost or support model of JavaFX, but since the question has come up, I'll add my 2 cents. The notion of requiring commercial vendors to pay to use the latest feature release of JavaFX is impractical at best. As a

Re: Talk about OPENJFX's future

Well a technical enforcement mechanism is impractical, it's true. What would be involved is a commercial license- an electronic thing like the agreement you clicked on when you downloaded the JDK from Oracle. For people using it commercially, you just make a payment through the usual payment

Re: Talk about OPENJFX's future

Two items  for us 1) focus on bug-free functionality over new features.  2) require a U.S. $50.00 a year fee per corporate entity for commercial application usage. This is very reasonable and  would finally secure JavaFX's future as a development platform.   I feel without 2) above we will

答复: Talk about OPENJFX's future

Well, it is happy hear that JavaFX perform well in embedded, my original intention isn’t condemn this video, just for an example, though it is little ridiculous.. 发件人: John-Val Rose 发送时间: 2018年9月21日 17:52 收件人: Johan Vos 抄送: a1032453...@163.com; openjfx-dev@openjdk.java.net 主题: Re: Talk about

Re: Talk about OPENJFX's future

That video is typical marketing “smoke and mirrors”. With no access to the code of either app, it is simply unfair and disingenuous to claim a performance advantage. I am certain I could post an almost identical comparison video where the results would be the complete opposite. Yeah, good

Re: Talk about OPENJFX's future

> > We can't defeat QT in performance, but we can defeat it at applicability > and just don't get too far behind QT in performance. (bad example > https://www.youtube.com/watch?v=Kh6K-yEp_JY) > That video demonstrates the creator has absolutely no development skills in Java, or he intentionally