Re: error in tutorial
Ty, If it’s so easy to fix then why don’t you just fix it? John-Val > On 28 Dec 2019, at 09:14, Ty Young wrote: > > >> On 12/27/19 4:19 AM, Johan Vos wrote: >> Hi David, >> >> What tutorial are you talking about? If you refer to https://openjfx.io, >> that is a community-initiative, developed at >> https://github.com/openjfx/openjfx-docs . >> So if you have issues and PR's, that is the place to submit and discuss >> with the other contributors to that site. > > > Only the Netbeans section has a warning telling you to delete src.zip. > Neither Intellij nor Eclipse do. > > > A user shouldn't have to do that anyway though! This could be easily fixed. > Literally all you need to do is in this section: > > > // Zip module sources for standalone SDK > // > // NOTE: the input is taken from the modular-sdk/modules_src dir > // so that we don't have to duplicate the logic and create another > // temporary directory. This is somewhat inelegant, since the bundled sdk > // and the standalone sdk should be independent of one another, but seems > // better than the alternatives. > def zipSourceFilesTask = > project.task("zipSourceFilesStandalone$t.capital", type: Zip, dependsOn: > buildModulesTask) { > destinationDir = file("${standaloneLibDir}") > archiveName = standaloneSrcZipName > includeEmptyDirs = false > from modulesSrcDir > include "**/*.java" > } > > > change:
Re: Gitter chat + StackOverflow [was: Concatenating transforms to scale positions but not objects]
I’ve all but given up on StackOverflow. It seems to be a haven for trolls or control freaks who deem perfectly reasonable questions as off-topic or inappropriate whereby the question then gets put on hold and can’t be answered. It’s ridiculous and makes the forum almost unusable. Some people enjoy the power they have to make this happen and have no interest in helping you or assisting in having your question answered. Sad. > On 13 Aug 2019, at 20:34, Mark Raynsford wrote: > > On 2019-08-12T14:25:37 +0100 > Mark Raynsford wrote: >> >> Hello! >> >> Here's the StackOverflow question: >> >> https://stackoverflow.com/questions/57461988/using-an-alternate-coordinate-system-inside-a-pane-or-region > > And, right on cue, the question has been marked as "off-topic". > > I don't believe that StackOverflow is suitable for general community > support. At least half of the interactions I have had with it have ended > similarly. > > Thanks, Michael, for attempting to respond on StackOverflow. > Unfortunately, the somewhat rabid moderators have decided that my > question isn't worth asking and that your response isn't worth > listening to. Sadness. > > -- > Mark Raynsford | http://www.io7m.com >
Re: Update openjfx.io to JavFX12?
Thanks Johan. Your contributions certainly do not go unnoticed, nor unappreciated, > On 30 Mar 2019, at 04:17, Nir Lisker wrote: > > Thanks Johan, I was actually not aware of this repo, I guess I missed it > when it was brought up. Will take a look. > >> On Fri, Mar 29, 2019 at 8:10 PM Johan Vos wrote: >> >> Yes, this should be 12 indeed. It's on our todo-list, but if you or anyone >> else want to update it, you can create a PR at >> https://github.com/openjfx/openjfx.github.io >> >> While this site is initiated by Gluon, I want to stress that openjfx.io >> really is a community website, hence I highly encourage participation. >> >> - Johan >> >>> On Fri, Mar 29, 2019 at 5:40 PM Nir Lisker wrote: >>> >>> Hi, >>> >>> The main page at https://openjfx.io still shows JavaFX11 even though 12 >>> is >>> released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the >>> main page show the latest version regardless? >>> >>> - Nir >>> >>
Re: Update openjfx.io to JavFX12?
+1 > On 30 Mar 2019, at 03:28, Nir Lisker wrote: > > Hi, > > The main page at https://openjfx.io still shows JavaFX11 even though 12 is > released. Is it because Gluon offers LTS for 11 and not 12? Shouldn't the > main page show the latest version regardless? > > - Nir
Re: openjfx-dev Digest, Vol 86, Issue 7
Upon reflection Ramon, and not being fully aware of the existing modularisation of JavaFX, I now agree with your suggestion. Graciously, John-Val > On 8 Jan 2019, at 01:44, Ramon Santiago wrote: > > I thank the community for their feedback. > > To clarify my original comments, I would consider "core" UI Controls as > those at the >javafx.scene.control level but; >not javafx.scene.chart >nor javafx.scene.web, which is already in a separate module >etc... > > I still believe that the charts should be put in their own module. > I understand that this opinion is not shared by others. > > > >> On Mon, Jan 7, 2019 at 7:00 AM wrote: >> >> Send openjfx-dev mailing list submissions to >>openjfx-dev@openjdk.java.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >>https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev >> or, via email, send a message with subject or body 'help' to >>openjfx-dev-requ...@openjdk.java.net >> >> You can reach the person managing the list at >>openjfx-dev-ow...@openjdk.java.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of openjfx-dev digest..." >> >> >> Today's Topics: >> >> 1. Re: Has any consideration been made to move the Charts into s >> separate module? (Tom Eugelink) >> 2. Re: Has any consideration been made to move the Charts into s >> separate module? (John-Val Rose) >> 3. Re: JavaFX Content Rendering & Resizing and Font Bugs In >> Linux (Ty Young) >> >> >> -- >> >> Message: 1 >> Date: Sun, 6 Jan 2019 13:16:35 +0100 >> From: Tom Eugelink >> Cc: openjfx-dev@openjdk.java.net >> Subject: Re: Has any consideration been made to move the Charts into s >>separate module? >> Message-ID: <965fc039-fba7-f005-08b1-bc2257f41...@tbee.org> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> I'm responding to your "moving he charts to a separate JPMS? module". It >> would make sense to have a javafx.charts, but at least charts are not in >> javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal >> JPMS module to have them in. But since they are now, it's not really worth >> a refactor. Given the typical size of a controls application, the charts >> classes won't make much of a difference. >> >> Whether charts belong in OpenJFX in the first place, and this what I think >> you mean with "core" (you have not established that concept either), is >> another topic. I would say no, the chart library of Gerrit illustates that. >> But someone at some point thought it was a good idea, just like half of >> Maven is/was in the JRE (a new HTTP client implementation???). So because >> of backward compatibility keeping in OpenJFX what was in Oracle's JRE makes >> sense. Call it historical debt or something. We just need a better >> alternative and then the classes can be removed at some point in the future. >> >> >>> On 6-1-2019 10:43, John-Val Rose wrote: >>> So Tom are you saying that javafx.base and javafx.graphics are the only >> ?core? modules in JavaFX? >>> >>> Has that ever been officially stated or established? >>> >>> How can javafx.controls or javafx.fxml not be considered core modules? >>> >>> There?s not much you can do with JavaFX without controls and FXML >> (albeit optional) is a critical part of most JavaFX apps. >>> >>>> On 6 Jan 2019, at 20:27, Tom Eugelink wrote: >>>> >>>> But (I assumed charts was in core as Ramon said) taking a look at the >> javadoc; charts are in the controls module, not in the core (javafx-base or >> javafx-graphics). So that seems quite ok. >>>> >>>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html >>>> >>>> >>>>> On 6-1-2019 02:58, John-Val Rose wrote: >>>>> I doubt any JavaFX application would use ALL the features so couldn?t >> you make the same argument for ?detachment? about many other parts of >> JavaFX? >>>>> >>>>> And what are the ?core components?? That is probably a subjective >> question. >>>>> >>>>>> On 6 Jan 2019, at 00:56, Ramon Santiago >> wrote: >>>>>> >>>>>
Re: Has any consideration been made to move the Charts into s separate module?
I think we actually agree Tom. I have not established what is “core” JavaFX simply because it has never crossed my mind that some modules are “core” whereas others must (by inference) be “peripheral”. I don’t see any value in refactoring charts into their own module given that, as I said, without controls there’s not much value in using JavaFX. There are lots of really good 3rd-party controls libraries such as those of Gerrit that you mentioned but there are numerous other 3rd-party JavaFX libraries that do not relate to controls at all. I guess I just don’t see any reason to strip JavaFX right down to the “core” (whatever that is) by for example moving charts or any other specific type of control into separate JPMS modules. And does anyone have some actual real-world stats as to how frequently charts are used? I, for one, certainly do not view them as “dead weight”. > On 6 Jan 2019, at 23:16, Tom Eugelink wrote: > > I'm responding to your "moving he charts to a separate JPMS module". It > would make sense to have a javafx.charts, but at least charts are not in > javafx.graphics or lower. Javafx.controls is IMHO an okay-but-not-ideal JPMS > module to have them in. But since they are now, it's not really worth a > refactor. Given the typical size of a controls application, the charts > classes won't make much of a difference. > > Whether charts belong in OpenJFX in the first place, and this what I think > you mean with "core" (you have not established that concept either), is > another topic. I would say no, the chart library of Gerrit illustates that. > But someone at some point thought it was a good idea, just like half of Maven > is/was in the JRE (a new HTTP client implementation???). So because of > backward compatibility keeping in OpenJFX what was in Oracle's JRE makes > sense. Call it historical debt or something. We just need a better > alternative and then the classes can be removed at some point in the future. > > >> On 6-1-2019 10:43, John-Val Rose wrote: >> So Tom are you saying that javafx.base and javafx.graphics are the only >> “core” modules in JavaFX? >> >> Has that ever been officially stated or established? >> >> How can javafx.controls or javafx.fxml not be considered core modules? >> >> There’s not much you can do with JavaFX without controls and FXML (albeit >> optional) is a critical part of most JavaFX apps. >> >>> On 6 Jan 2019, at 20:27, Tom Eugelink wrote: >>> >>> But (I assumed charts was in core as Ramon said) taking a look at the >>> javadoc; charts are in the controls module, not in the core (javafx-base or >>> javafx-graphics). So that seems quite ok. >>> >>> https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html >>> >>> >>>> On 6-1-2019 02:58, John-Val Rose wrote: >>>> I doubt any JavaFX application would use ALL the features so couldn’t you >>>> make the same argument for “detachment” about many other parts of JavaFX? >>>> >>>> And what are the “core components”? That is probably a subjective question. >>>> >>>>> On 6 Jan 2019, at 00:56, Ramon Santiago wrote: >>>>> >>>>> Yes, I meant removing charts from the core of JavaFX and moving he charts >>>>> to a separate JPMS module. >>>>> >>>>> Why? They are not really core components are they? They are dead weight >>>>> in applications that never will use them. >>>>> >>>>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose >>>>>> wrote: >>>>>> Hi Ramon, >>>>>> >>>>>> I personally have never seen or heard of any such discussion and I’m not >>>>>> entirely sure in which context you are using the word “module”. >>>>>> >>>>>> Do you meaning simply removing charts from the core of JavaFX or do you >>>>>> mean creating the charts as an actual module within JPMS? >>>>>> >>>>>> Either way, can you tell us why you have thought of this idea? >>>>>> >>>>>> Graciously, >>>>>> >>>>>> John-Val >>>>>> >>>>>>> On 6 Jan 2019, at 00:33, Ramon Santiago >>>>>>> wrote: >>>>>>> >>>>>>> -- >>>>>>> rjs >>>>> -- >>>>> rjs >>> >
Re: Has any consideration been made to move the Charts into s separate module?
So Tom are you saying that javafx.base and javafx.graphics are the only “core” modules in JavaFX? Has that ever been officially stated or established? How can javafx.controls or javafx.fxml not be considered core modules? There’s not much you can do with JavaFX without controls and FXML (albeit optional) is a critical part of most JavaFX apps. > On 6 Jan 2019, at 20:27, Tom Eugelink wrote: > > But (I assumed charts was in core as Ramon said) taking a look at the > javadoc; charts are in the controls module, not in the core (javafx-base or > javafx-graphics). So that seems quite ok. > > https://docs.oracle.com/javase/9/docs/api/javafx.controls-summary.html > > >> On 6-1-2019 02:58, John-Val Rose wrote: >> I doubt any JavaFX application would use ALL the features so couldn’t you >> make the same argument for “detachment” about many other parts of JavaFX? >> >> And what are the “core components”? That is probably a subjective question. >> >>> On 6 Jan 2019, at 00:56, Ramon Santiago wrote: >>> >>> Yes, I meant removing charts from the core of JavaFX and moving he charts >>> to a separate JPMS module. >>> >>> Why? They are not really core components are they? They are dead weight in >>> applications that never will use them. >>> >>>> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose wrote: >>>> Hi Ramon, >>>> >>>> I personally have never seen or heard of any such discussion and I’m not >>>> entirely sure in which context you are using the word “module”. >>>> >>>> Do you meaning simply removing charts from the core of JavaFX or do you >>>> mean creating the charts as an actual module within JPMS? >>>> >>>> Either way, can you tell us why you have thought of this idea? >>>> >>>> Graciously, >>>> >>>> John-Val >>>> >>>>> On 6 Jan 2019, at 00:33, Ramon Santiago wrote: >>>>> >>>>> -- >>>>> rjs >>> >>> -- >>> rjs > >
Re: Has any consideration been made to move the Charts into s separate module?
I doubt any JavaFX application would use ALL the features so couldn’t you make the same argument for “detachment” about many other parts of JavaFX? And what are the “core components”? That is probably a subjective question. > On 6 Jan 2019, at 00:56, Ramon Santiago wrote: > > Yes, I meant removing charts from the core of JavaFX and moving he charts to > a separate JPMS module. > > Why? They are not really core components are they? They are dead weight in > applications that never will use them. > >> On Sat, Jan 5, 2019 at 8:44 AM John-Val Rose wrote: >> Hi Ramon, >> >> I personally have never seen or heard of any such discussion and I’m not >> entirely sure in which context you are using the word “module”. >> >> Do you meaning simply removing charts from the core of JavaFX or do you mean >> creating the charts as an actual module within JPMS? >> >> Either way, can you tell us why you have thought of this idea? >> >> Graciously, >> >> John-Val >> >> > On 6 Jan 2019, at 00:33, Ramon Santiago wrote: >> > >> > -- >> > rjs > > > -- > rjs
Re: Has any consideration been made to move the Charts into s separate module?
Hi Ramon, I personally have never seen or heard of any such discussion and I’m not entirely sure in which context you are using the word “module”. Do you meaning simply removing charts from the core of JavaFX or do you mean creating the charts as an actual module within JPMS? Either way, can you tell us why you have thought of this idea? Graciously, John-Val > On 6 Jan 2019, at 00:33, Ramon Santiago wrote: > > -- > rjs
Re: Q: Rotated labels, layout and reflow
Yes, you are absolutely right John and again I’m sorry that I did not initially see the relevance of your question for this list. I do now and I like your ideas :-) > On 15 Dec 2018, at 22:06, John Hendrikx wrote: > > > I asked here because, although not a bug, it may be a good feature to support > -- and I was looking for confirmation that this really isn't currently > possible. It's not a bug because a rotation transform is expected to not > change the layout bounds. Making use of Group fixes the layout bounds but > makes it impossible to do proper dynamic layouts with labels that have been > rotated 90 degrees. > > Questions similar like this one, without good resolutions, show up on forums > and stackoverflow, and, looking at the bug database, I think even some of the > graph components part of JavaFX that support rotated labels have similar > layout problems when texts needs to be cut-off or reflowed in such labels. > > I even looked at MigLayout already, and noticed a similar issue reported > there where rotated labels are not handled properly, probably because the > layout bounds don't take the rotation into account, which no doubt MigLayout > relies on to do its thing. > > Now, I would love to contribute a fix for this (I contributed some small > things before), however I think this might be a tough issue to resolve. The > way I see it, this cannot be solved without Label taking the rotation into > account itself and providing proper layout bounds -- this is needed because > Label decides if text reflow needs to occur depending on where it is placed, > and this information is lost when it is put in a Group. > > So I think Label(ed) would need a new Rotate property, which only supports 0, > 90, 180 and 270 degrees, or perhaps an extension to the text direction > property (left-right, right-left, top-down, down-top), but I think that it > serves a different purpose that is independent from rotation. > > With this extra information, Label can then do the proper layout calculations > with potential reflow of text and provide correct layout bounds. The actual > text rendering would also need to be rotated somehow, and I'm not quite sure > how that would be accomplished yet for Labels. > > All in all, it sounds like quite some effort that would need a good design, > especially since Label already has a short-cut property to add a Rotate > transform that cannot be re-used for this, so a new property would have to > make the difference very clear. > > --John > >> On 15/12/2018 09:18, Tom Eugelink wrote: >> It's a bit grey. If this goes towards a bug in the layout, it could be >> considered OpenJFX development. It could also go towards a patch, >> because instead of using Canvas I would suggest (John) to look at the >> HBox and see if you can figure out why it is not doing what you want. >> And if that is too complex; write a layout that does this, and >> contribute it to OpenJFX, ControlsFX or JFXtras. (I believe OpenJFX also >> is the sum of all the extending libraries, not making the suck-it-all-in >> mistake Java made.) The layout logic should be similar to when doing it >> in Canvas, only reusable. >> >> Also I have found that when rotating is involved, a lot of layouts do >> not what you expect them to do. Have you given MigLayout a try? It >> sometimes has surprising results (both positive and negative) ;-) >> >> >> >> >>> On 15-12-2018 03:14, John-Val Rose wrote: >>> My feedback would to ask this kind of question on a more appropriate >>> list or forum. >>> >>> I believe this list is exclusively to discuss issues related to the >>> development of OpenJFX itself. >>> >>> Graciously, >>> >>> John-Val >>> >>>> On 15 Dec 2018, at 12:50, John Hendrikx wrote: >>>> >>>> >>>> (Sent this twice, first message got sent prematurely) >>>> >>>> Hi list, >>>> >>>> I get the impression that rotation of Labels needs to be something >>>> that is directly supported by Label instead of handling this with a >>>> Rotate transform (setRotate). >>>> >>>> I want to achieve something quite trivial if no rotation was >>>> involved, a layout like this, an HBox with 3 labels in it: >>>> >>>> +-HBox+ >>>> || Long text that can reflow to multiple || >>>> | Short Text | lines if needed...| Short Text | >>
Re: Q: Rotated labels, layout and reflow
Tom, you are right - it is a bit grey and I'm glad you were able to offer better advice than I could. Sorry to John for possibly coming across as rude. I wasn't trying to be. I simply didn't think this was the best place to get your question answered. *Graciously,* *John-Val* On Sat, 15 Dec 2018 at 19:19, Tom Eugelink wrote: > It's a bit grey. If this goes towards a bug in the layout, it could be > considered OpenJFX development. It could also go towards a patch, because > instead of using Canvas I would suggest (John) to look at the HBox and see > if you can figure out why it is not doing what you want. And if that is too > complex; write a layout that does this, and contribute it to OpenJFX, > ControlsFX or JFXtras. (I believe OpenJFX also is the sum of all the > extending libraries, not making the suck-it-all-in mistake Java made.) The > layout logic should be similar to when doing it in Canvas, only reusable. > > Also I have found that when rotating is involved, a lot of layouts do not > what you expect them to do. Have you given MigLayout a try? It sometimes > has surprising results (both positive and negative) ;-) > > > > > On 15-12-2018 03:14, John-Val Rose wrote: > > My feedback would to ask this kind of question on a more appropriate > list or forum. > > > > I believe this list is exclusively to discuss issues related to the > development of OpenJFX itself. > > > > Graciously, > > > > John-Val > > > >> On 15 Dec 2018, at 12:50, John Hendrikx wrote: > >> > >> > >> (Sent this twice, first message got sent prematurely) > >> > >> Hi list, > >> > >> I get the impression that rotation of Labels needs to be something that > is directly supported by Label instead of handling this with a Rotate > transform (setRotate). > >> > >> I want to achieve something quite trivial if no rotation was involved, > a layout like this, an HBox with 3 labels in it: > >> > >> +-HBox+ > >> || Long text that can reflow to multiple || > >> | Short Text | lines if needed...| Short Text | > >> || || > >> +-+ > >> > >> The center label would be given grow Priority.ALWAYS. > >> > >> Now... the rotated version just goes wrong in so many ways. > >> > >> First, I need to use Groups in order to get the layout bounds > reasonable... however, these are unaware of how much space is available and > will kill the reflow in the center Label. > >> > >> If I put a Group around the whole HBox, the same issue occurs as the > Group blocks any awareness of how big the area is where the three labels > are going to appear, effectively rendering the center label as one long > line. > >> > >> What I'm actually trying to achieve is a layout that looks like this: > >> > >>++---+ > >>| T | | > >>| e | | > >>| x | | > >>| t | | > >>++ | > >>|| | > >>| T | | > >>| e | Image | > >>| x | | > >>| t | | > >>|| | > >>++ | > >>| T | | > >>| e | | > >>| x | | > >>| t | | > >>++---+ > >> > >> Except of course the left area should be the rotated HBox. > >> > >> Is this really not possible at the moment, without using a Canvas or > something and a lot of layout calculations (to get reflow working)? > >> > >> Any feedback appreciated :) > >> > >> --John > > >
Re: Q: Rotated labels, layout and reflow
My feedback would to ask this kind of question on a more appropriate list or forum. I believe this list is exclusively to discuss issues related to the development of OpenJFX itself. Graciously, John-Val > On 15 Dec 2018, at 12:50, John Hendrikx wrote: > > > (Sent this twice, first message got sent prematurely) > > Hi list, > > I get the impression that rotation of Labels needs to be something that is > directly supported by Label instead of handling this with a Rotate transform > (setRotate). > > I want to achieve something quite trivial if no rotation was involved, a > layout like this, an HBox with 3 labels in it: > > +-HBox+ > || Long text that can reflow to multiple || > | Short Text | lines if needed...| Short Text | > || || > +-+ > > The center label would be given grow Priority.ALWAYS. > > Now... the rotated version just goes wrong in so many ways. > > First, I need to use Groups in order to get the layout bounds reasonable... > however, these are unaware of how much space is available and will kill the > reflow in the center Label. > > If I put a Group around the whole HBox, the same issue occurs as the Group > blocks any awareness of how big the area is where the three labels are going > to appear, effectively rendering the center label as one long line. > > What I'm actually trying to achieve is a layout that looks like this: > > ++---+ > | T | | > | e | | > | x | | > | t | | > ++ | > || | > | T | | > | e | Image | > | x | | > | t | | > || | > ++ | > | T | | > | e | | > | x | | > | t | | > ++---+ > > Except of course the left area should be the rotated HBox. > > Is this really not possible at the moment, without using a Canvas or > something and a lot of layout calculations (to get reflow working)? > > Any feedback appreciated :) > > --John
Re: 3D Canvas Node?
I also believe that such a component would be highly beneficial & I myself have suggested it many times in the past. To Chengen Zhao, you may not be aware but there is a new mailing list where it may be more appropriate to ask this question. That list is openjfx-disc...@openjdk.java.net I hope this helps. Graciously, John-Val Rose > On 15 Oct 2018, at 12:32, Chengen Zhao wrote: > > Hi: > > We are currently developing games by using JavaFX > one feature would be nice to have is 3D Canvas node > so is it possible to have this feature in the future release? > > Thanks
Re: JavaFX 11 on Android
Johan, I’m guessing that Gluon Mobile and GluonVM will run on Android with JavaFX 11 (eventually at least). Is this correct? Graciously, John-Val Rose Rosethorn Technology > On 5 Oct 2018, at 06:00, Kevin Rushforth wrote: > > >> My proposal would therefore be that I split the changes into >> Android/Dalvik/Monocle changes that do not affect any other platform, and >> create PR's for merging these changes in upstream. While my prototype is >> working (see https://twitter.com/johanvos/status/1047804607320260608) I >> need to clean up the patches, and I suggest I create smaller PR's that are >> easier to digest. > > This seems like a fine idea. > >> For the changes in the common classes, I think it's best to use a fork, or >> to patch the system at build time -- rather than polluting the main >> repository with reflection-based checks. > > As does this. > > -- Kevin > > >> On 10/4/2018 10:01 AM, Johan Vos wrote: >> Hi, >> >> I worked from the openjfx/develop repository and created a version that >> works on Android (will work on iOS soon). >> This required some changes, as we're running on top of the Android VM, >> which is not really Java (not even close). >> The longer-term goal is to run a JVM on Android as well, but that is not >> something to discuss in this topic. >> >> The changes I had to make are in this diff: >> https://github.com/javafxports/openjdk-jfx/compare/develop...johanvos:android >> >> There are a number of changes: >> >> 1. Changes in the Android specific files (e.g. FXDalvikEntity): those are >> mainly changes we did in the 8-tree, but that were never sent upstream. I >> think most of those can be upstreamed (after cleanup and review of course) >> >> 2. Changes in Monocle, mainly related to scale factor and HiDPI. Those can >> probably be upstreamed as well >> >> 3. Changes in the buildSrc/dalvik.gradle. Those are android-only, so can be >> upstreamed too. >> >> 4. Changes in common java classes (e.g. no System.Logger). Those are a >> problem. >> >> While I am in favour of leveraging the latest version of Java for doing >> JavaFX development, I do realise this breaks the Android port (not the iOS >> port, as we use a VM based on OpenJDK already there). >> While in theory we could deal with this using reflection (and this has been >> done in the 8-tree, e.g. for isIdeographic()), I don't think this is a good >> idea. >> >> My proposal would therefore be that I split the changes into >> Android/Dalvik/Monocle changes that do not affect any other platform, and >> create PR's for merging these changes in upstream. While my prototype is >> working (see https://twitter.com/johanvos/status/1047804607320260608) I >> need to clean up the patches, and I suggest I create smaller PR's that are >> easier to digest. >> >> For the changes in the common classes, I think it's best to use a fork, or >> to patch the system at build time -- rather than polluting the main >> repository with reflection-based checks. >> >> Thoughts? >> >> - Johan >
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 programmers can write slow code (especially if you have a motive)... On 21 Sep 2018, at 19:29, Johan Vos wrote: >> >> 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 misleads the viewer. I leave it to the reader to > judge what would be worst. > > I am not going to make performance statements without numbers, but my first > observations using JavaFX 11 with the Bellsoft Liberica VM are very > encouraging (see https://gluonhq.com/javafx-11-early-access-on-embedded/) > > - Johan
Re: which technology should give preference
Yes, as I suggested too, this is probably not the appropriate forum to post such questions. I tried to say this in an inoffensive way as possible because we are all human and make simple mistakes. I wish Amno all the best with their JavaFX app and I would suggest they check-out the products of Gluon when it comes to porting the app to mobile. Their URL is http://gluonhq.com Graciously, John-Val > On 7 Sep 2018, at 10:22, John-Val Rose wrote: > > Thanks Michael - your answer was way better than mine! > >> On 7 Sep 2018, at 10:19, Michael Ennen wrote: >> >> Amno, >> >> It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add >> anything, per se (in terms of nodes, controls, etc.) FXML allows for >> decoupling >> the specific UI configuration (in terms of what nodes contain which and >> their >> positions, etc.). Basically it is the most sustainable (in terms of >> increasing >> application size/scope) practice to use FXML for setting up the initial >> scenes >> (and perhaps also wiring event listeners) >> >> In the Android world it is equivalent to using the Layout Editor (similar >> to FXML) >> versus making the scene programmatically by calling constructors, setting >> ownership, >> positions, constraints, etc. There is nothing that can be done using FXML >> that can't >> be done using pure Java. >> >> Cheers, >> Michael Ennen >> >>> On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: >>> >>> I am learning hands-on how to program using JavaFX and in the process >>> doing so I’ve come across FXML; which I find most interesting. Since the >>> principal is “Think hand held device first” -TH2DF, my intention is to >>> port the my future application to Android device, but I am concerned >>> that there will be too many issues when doing that. So, my question is, >>> which technology should give preference to, JavaFX or FXML? >>> >>> Please, keep in mind that I am using a Windows 8.1 machine and >>> Eclipse-Photon. >>> >>> >>> Thanks in advance >>> >>> -- >>> ArbolOne >>> Using Fire Fox and Thunderbird. >>> Developing using Java, C/C++, HTM/CSS and JS as our platform has been >>> exciting and most rewarding. >>> [ Sí ] >>> >>>
Re: which technology should give preference
Thanks Michael - your answer was way better than mine! > On 7 Sep 2018, at 10:19, Michael Ennen wrote: > > Amno, > > It is not a zero-sum choice. FXML is a part of JavaFX. FXML does not add > anything, per se (in terms of nodes, controls, etc.) FXML allows for > decoupling > the specific UI configuration (in terms of what nodes contain which and > their > positions, etc.). Basically it is the most sustainable (in terms of > increasing > application size/scope) practice to use FXML for setting up the initial > scenes > (and perhaps also wiring event listeners) > > In the Android world it is equivalent to using the Layout Editor (similar > to FXML) > versus making the scene programmatically by calling constructors, setting > ownership, > positions, constraints, etc. There is nothing that can be done using FXML > that can't > be done using pure Java. > > Cheers, > Michael Ennen > >> On Thu, Sep 6, 2018 at 4:48 PM AmnoJeeuw wrote: >> >> I am learning hands-on how to program using JavaFX and in the process >> doing so I’ve come across FXML; which I find most interesting. Since the >> principal is “Think hand held device first” -TH2DF, my intention is to >> port the my future application to Android device, but I am concerned >> that there will be too many issues when doing that. So, my question is, >> which technology should give preference to, JavaFX or FXML? >> >> Please, keep in mind that I am using a Windows 8.1 machine and >> Eclipse-Photon. >> >> >> Thanks in advance >> >> -- >> ArbolOne >> Using Fire Fox and Thunderbird. >> Developing using Java, C/C++, HTM/CSS and JS as our platform has been >> exciting and most rewarding. >> [ Sí ] >> >>
Re: which technology should give preference
FXML is “part” of JavaFX. It’s the format used to specify the UI of a JavaFX application. Plus I don’t think this is the appropriate list to post such questions as it is intended as a forum to discuss the development of JavaFX itself. > On 7 Sep 2018, at 09:47, AmnoJeeuw wrote: > > I am learning hands-on how to program using JavaFX and in the process doing > so I’ve come across FXML; which I find most interesting. Since the principal > is “Think hand held device first” -TH2DF, my intention is to port the my > future application to Android device, but I am concerned that there will be > too many issues when doing that. So, my question is, which technology should > give preference to, JavaFX or FXML? > > Please, keep in mind that I am using a Windows 8.1 machine and Eclipse-Photon. > > > Thanks in advance > > -- > ArbolOne > Using Fire Fox and Thunderbird. > Developing using Java, C/C++, HTM/CSS and JS as our platform has been > exciting and most rewarding. > [ Sí ] >
Re: Is JavaFX going to truly be a community project?
Mike, can you explain what you mean by a “JavaFX website”? > On 3 Sep 2018, at 02:59, Mike Hearn wrote: > > I believe you're over-thinking this Pedro. A quote from Margaret Thatcher > springs to mind: > > "They are casting their problems on society and who is society? There is no >> such thing! There are individual men and women and there are families and >> no government can do anything except through people and people look to >> themselves first." > > > Her point was that when someone says "the community should do this", that's > an abstraction - the community is nothing more than people, sometimes > individuals and sometimes organised into companies. Gluon and Oracle are > both clearly critical parts of the JavaFX community and that's a good > thing. I'm not sure why it would be off-putting. After all, JavaFX is based > on Java and the Java community is mostly made of companies too (Oracle, Red > Hat, Intel, Azul etc). > > Perhaps the JavaFX community will get more organised with time - I believe > the "community-ness" feeling would be significantly enhanced with simple > things like a JavaFX website. Perhaps you can contribute such a thing, as > it would not involve core JavaFX hacking?
Re: Is JavaFX going to truly be a community project?
Hi Pedro, I just happen to agree with you in this issue. But, out of all the possible new custodians of JavaFX, I have to say that I am always in awe of what Johan and Gluon have already contributed and accomplished. So how do we ensue that OpenJFX is truly “open”? I agree that even though Gluon are doing a fantastic job, JavaFX should not be a “Gluon product”. I think it’s a great move for Oracle to basically relinquish control of JavaFX - but to whom? I’m not familiar enough with FOSS projects to offer any sage advice but I totally agree that a “community” project has to be as open to everyone as possible and no person or entity should have a commercial advantage over others. So, basically I like your question, I don’t believe the current scenario is satisfactory but unfortunately I confess I can’t offer any suggestions of better scenarios. Graciously, John-Val Rose > On 1 Sep 2018, at 22:00, Pedro Duque Vieira > wrote: > > Hi, > > For JavaFX to start being, truly, a community project it is important that > it is perceived as a real community effort. Right now it's starting to look > more like it's changing hands, from being an Oracle project to being a > Gluon project. > > I don't have anything against Gluon, I'd say the same if for instance, > instead of Gluon it was JPro or Karakun, or whatever... > > Hosting the JavaFX docs, builds, installations, etc on a company owned site > or a company endorsed site sounds like a really bad idea. Which is what's > happening right now. If it's to be a community project it should be owned > by the community as a whole. As well as being perceived to be owned by the > community as a whole. > > Being a one company project will deter the contributions of other players > in the JavaFX space. Other players that also offer consultancy services, > and JavaFX products will have a big disadvantage towards the company > hosting the JavaFX assets and downloads. At the very minimum think about > the huge advantage this company will have in publicity when compared to the > others. > > A community project is a project where various players join efforts to > mutually benefit each other. As soon as this starts being a project that's > benefiting one particular company more than the others it ceases to be a > community project. > > I don't think that anyone would like to join in on the efforts in this > scenario. > > Thanks, > > > > -- > Pedro Duque Vieira - https://www.pixelduke.com
Re: OpenGL deprecated in OS-X
I’m doing some work with Vulkan at the moment so maybe I’ll be able to help out with Vk support for JavaFX. John-Val > On 5 Jun 2018, at 17:18, Johan Vos wrote: > > Ever since Apple deprecated the developer-oriented Apple ][ , I failed to > appreciate their decisions. But so be it. > > The good thing is that the structure of the OpenJFX project allows for > different rendering pipelines without much impact on other code. > Therefore, I think it would be a nice sandbox experiment to have a Metal and > a Vulkan pipeline. > > But I agree with Kevin, we don't need a replacement for OpenGL in the Java 11 > timeframe :) > > - Johan > > >> On Tue, Jun 5, 2018 at 12:35 AM John-Val Rose wrote: >> Unfortunately Apple is doing exactly what Microsoft did during the “Great >> API Wars”. During this time, MS decided to go with its own exclusive >> graphics API namely Direct 3D as part of their whole DirectX technology >> instead of the obvious approach of supporting OpenGL fully. >> >> These days, GPU drivers for DirectX work much better on Windows than those >> for OpenGL. >> >> The same will now apply for Metal drivers versus OpenGL drivers on MacOS. >> >> This is all about “vendor lock-in” and can be seen with other technologies >> like WebKit and Blink for example. >> >> Of course this is bad news for the developers but devs are not the core >> market for Windows, Apple or Google/Android hardware. >> >> The bright light on the horizon is Vulkan from Khronos which started out >> life as OpenGL 5 but is now being pushed as the ultimate cross platform >> graphics API. >> >> Even Microsoft have jumped on board and Vulkan driver support on Windows is >> good. >> >> We will have to wait and see but having a situation where OpenGL, DirectX, >> Metal and Vulkan are all important graphics APIs simultaneously is clearly >> not tenable. >> >> > On 5 Jun 2018, at 06:51, Tom Schindl wrote: >> > >> > Hi, >> > >> > I don‘t know what the Apple guys are smoking but they just deprecated >> > OpenGL. The question is what does this mean for JavaFX. >> > >> > See https://developer.apple.com/macos/whats-new/ >> > >> > Tom >> > >> > Von meinem iPhone gesendet
Re: OpenGL deprecated in OS-X
Unfortunately Apple is doing exactly what Microsoft did during the “Great API Wars”. During this time, MS decided to go with its own exclusive graphics API namely Direct 3D as part of their whole DirectX technology instead of the obvious approach of supporting OpenGL fully. These days, GPU drivers for DirectX work much better on Windows than those for OpenGL. The same will now apply for Metal drivers versus OpenGL drivers on MacOS. This is all about “vendor lock-in” and can be seen with other technologies like WebKit and Blink for example. Of course this is bad news for the developers but devs are not the core market for Windows, Apple or Google/Android hardware. The bright light on the horizon is Vulkan from Khronos which started out life as OpenGL 5 but is now being pushed as the ultimate cross platform graphics API. Even Microsoft have jumped on board and Vulkan driver support on Windows is good. We will have to wait and see but having a situation where OpenGL, DirectX, Metal and Vulkan are all important graphics APIs simultaneously is clearly not tenable. > On 5 Jun 2018, at 06:51, Tom Schindl wrote: > > Hi, > > I don‘t know what the Apple guys are smoking but they just deprecated OpenGL. > The question is what does this mean for JavaFX. > > See https://developer.apple.com/macos/whats-new/ > > Tom > > Von meinem iPhone gesendet
Re: Announcing EA builds of standalone JavaFX SDK
Thanks very much Kevin. This is a great step forward and will make all of our lives easier. Graciously, John-Val Rose > On 8 May 2018, at 17:43, Johan Vos wrote: > > Hi Kevin, > > Excellent work. > I confirm this is working for me. > > Java: openjdk 11-ea+12 for Linux > App from > https://github.com/gluonhq/projavafx9/tree/master/chapter1/HelloEarthRise/src/main/java/projavafx/helloearthrise/ui > (on > classpath) > > - Johan > > On Tue, May 8, 2018 at 1:11 AM Kevin Rushforth > wrote: > >> I am pleased to announce the first Early Access build of a standalone >> JavaFX SDK [1]. You can download it and run it using OpenJDK 10 or an >> OpenJDK 11 EA build. >> >> If your application is in an unnamed module (i.e., your app is on the >> classpath), you can run your application as follows, after unzipping the >> SDK bundle for your platform. >> >> $ java --module-path $PATH_TO_FX/javafx-sdk-11 >> --add-modules=javafx.controls,javafx.fxml MyApp >> >> This assumes you don't need media or web. If you do, then add those >> modules, too. Note that since javafx.web "requires transitive >> javafx.controls", you can omit javafx.controls if you add javafx.web. >> >> If you are running a modular application, then you don't need the >> "--add-modules" option. >> >> Note that this is a stepping stone to javafx modules in a repository >> like Maven. >> >> Please test your applications with the SDK and give us feedback. >> >> Thanks. >> >> -- Kevin >> >> [1] http://jdk.java.net/openjfx/ >> >>
Re: future content of OpenJFX
OK, after Wolfgang’s comments, I will unleash my rant again in the “appropriate” thread as I feel that the lack of JavaFX adoption is very much due to the nature of the toolkit itself: Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. In general, I don’t understand all the limitations that people keep imposing on JavaFX as if we have to “settle” for what is basically a 2nd class citizen compared with toolkits in other languages. Why can’t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. Am I the only one that believes the world’s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? I understand the constraints imposed on Oracle staff but isn’t there anyone else out there in the community who shares my vision for JavaFX? It seems the general attitude is that JavaFX just needs to be a “better Swing”. Forget about this nonsense of “thinking outside the box”. There is NO BOX! JavaFX can and should be the best that we as a community can make it. And then we just keep making it better... If we don’t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. I’m sure Jyloo and others would be much more successful and get real ROI on their investment in JavaFX if JavaFX itself was “better” and more competitive. We don’t want developers in general to ask “Hmm, so I need a graphics toolkit. I mostly know Java pretty well so I guess that means JavaFX will just have to do even though I’d use Qt if I knew C++ because it’s sooo much better”. What we want is “Hmm, so I need a graphics toolkit. Let’s see what’s out there. Hey, this JavaFX thing looks awesome! It has all the features I need, performs really well, runs on most platforms and can be programmed by any JVM language! And there’s all those amazing IDEs and tools and Java developers are really easy to find. Yes, I think I’ll choose JavaFX for this new multi-million dollar system!” > On 8 Feb 2018, at 00:07, Wolfgang Zitzelsberger wrote: > > As a vendor of third party controls it's finally time for a feedback. We > create look and feels and controls mainly for Swing/JavaFX desktop business > applications. For us the most important things are: > > * Bugfixing - and we've already reported a lot over the past years > * Rock solid base controls > * An extendable API > * Behavior API > > Because of the API, in Java 9 for some methods the visibility changed from > protected to package local - in conjunction with JPMS it's pretty hard to > find proper workarounds. Some of our FX controls are pretty sophisticated > (e.g. our Table control) but all the open bugs makes further work pretty > expensive simply because it slows development extremely down. Even if we > noticed some higher activity in bug fixing, many open bugs are moved from one > release to the next without getting fixed. Another big issue is the bug > fixing latency - when we post a bug today it will be possibly fixed in Java > 11 or later. For us this means a new product feature can't be tested and > released before Java 11 - time goes by and in the meantime other technologies > win. > > Johan, JavaFX is much more popular on Google Trends now than Swing because > some of you guys praised JavaFX as the "successor of Swing" and often > followed the "Swing is dead" mantra. If you are looking for a competitor you > should take a look at web technologies or other non-Java products. IMHO Swing > is *not* a competitor it's simply the older brother. Anyway, this doesn't > matter in this discussion. For us creating complex JavaFX controls is more > complicated than in Swing - not because of JavaFX itself, it's mainly because > the JavaFX API is currently too restricted (way too many final and > package-only visible methods). > > We've already invested thousands of bucks in JavaFX development without any > ROI. Not a problem at all but at some point this is quite frustrating. And we > are far away from seeing a huge interest in JavaFX business products. BTW: > Any number of downloads can be misleading if you know nothing about the user > base - business, education, hobby, bot... > > Just my 2 cents. > > Cheers Wolfgang, > CEO of Jyloo Software > Germany >
Re: More community participation in JavaFX
Yes, I agree - sorry. I got a bit confused as to which thread I was “in” (while reading messages from each of them simultaneously) and there’s definitely a degree of overlap between the two of them topic-wise. Anyway, I vented - just not in the right place. I still hope for some feedback on said venting... > On 8 Feb 2018, at 03:42, Kevin Rushforth wrote: > > This has now veered off topic for this thread. It would be a fine topic for > the "future content of OpenJFX" thread. > > -- Kevin > > > John-Val Rose wrote: >> >> >> Well, not only do I think that a docking framework is *that* complex, I see >> it as an essential part of any serious graphics toolkit. >> >> In general, I don’t understand all the limitations that people keep imposing >> on JavaFX as if we have to “settle” for what is basically a 2nd class >> citizen compared with toolkits in other languages. >> >> Why can’t we just make JavaFX so compelling that developers from other >> languages are enticed by the feature set itself? There is no reason (other >> than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in >> terms of features, performance, tooling and adoption. >> >> Am I the only one that believes the world’s most popular and amazing >> programming language, platform and the JVM deserves a first class graphics >> toolkit? >> >> I understand the constraints imposed on Oracle staff but isn’t there anyone >> else out there in the community who shares my vision for JavaFX? >> >> It seems the general attitude is that JavaFX just needs to be a “better >> Swing”. >> >> Forget about this nonsense of “thinking outside the box”. >> >> There is NO BOX! >> >> JavaFX can and should be the best that we as a community can make it. >> >> And then we just keep making it better... >> >> If we don’t adopt such a vision and attitude then what is the point of doing >> anything at all? Just leave JavaFX to rot into oblivion and relegate Java to >> a server-side language only. >> >> >> >> >>> On 7 Feb 2018, at 19:25, Tom Eugelink wrote: >>> >>> Well, I believe he was hinting at that a docking framework is considered >>> more complex, there was no negative sentiment in that. Although I do not >>> think a docking framework is that complex, but maybe I'm wrong. >>> >>> And yes, ALMOST everyone is at ControlFX ;-) >>> >>> >>> >>> >>>> Jonathan - why do you *cough* at ideas like more complex controls and >>>> docking frameworks? >>>> >>>> I think that a docking framework especially would be a great addition to >>>> JavaFX. >>>> >>>> Am I missing something? >>>> >>>> >>>>> On 7 Feb 2018, at 18:16, Jonathan Giles >>>>> wrote: >>>>> >>>>> Obviously everyone is at ControlsFX instead ;-) >>>>> >>>>> Part of the drop I would suggest is simply that many of the itches >>>>> people >>>>> want to scratch are now scratched. Alternatively, the remaining itches >>>>> are >>>>> either in more complex controls (*cough* docking frameworks *cough*) or >>>>> in >>>>> areas beneath the controls APIs - performance, webview, etc - which are >>>>> more challenging and require greater levels of dedication. >>>>> >>>>> However, more generally, your point is well made - contribution to >>>>> JavaFX >>>>> does not need to be synonymous with contribution to OpenJFX. People who >>>>> find the challenges of the current OpenJFX requirements too great should >>>>> be >>>>> encouraged to involve themselves in projects such as JFXtras, etc. >>>>> >>>>> -- Jonathan >>>>> >>>>> >>>>>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >>>>>> >>>>>> Many years ago I had a discussion with Jonathan Giles about if the >>>>>> things >>>>>> that were being made in JFXtras would eventually become part of the >>>>>> JavaFX >>>>>> core. In the end I decided that, for me personally, I could do the >>>>>> things I >>>>>> wanted to perfectly in a separate project. The rigid structure that >>>>>> Java(FX) has to adh
Re: More community participation in JavaFX
Well, not only do I think that a docking framework is *that* complex, I see it as an essential part of any serious graphics toolkit. In general, I don’t understand all the limitations that people keep imposing on JavaFX as if we have to “settle” for what is basically a 2nd class citizen compared with toolkits in other languages. Why can’t we just make JavaFX so compelling that developers from other languages are enticed by the feature set itself? There is no reason (other than a lack of effort) why JavaFX cannot be on par with Qt or Xamarin in terms of features, performance, tooling and adoption. Am I the only one that believes the world’s most popular and amazing programming language, platform and the JVM deserves a first class graphics toolkit? I understand the constraints imposed on Oracle staff but isn’t there anyone else out there in the community who shares my vision for JavaFX? It seems the general attitude is that JavaFX just needs to be a “better Swing”. Forget about this nonsense of “thinking outside the box”. There is NO BOX! JavaFX can and should be the best that we as a community can make it. And then we just keep making it better... If we don’t adopt such a vision and attitude then what is the point of doing anything at all? Just leave JavaFX to rot into oblivion and relegate Java to a server-side language only. > On 7 Feb 2018, at 19:25, Tom Eugelink wrote: > > Well, I believe he was hinting at that a docking framework is considered > more complex, there was no negative sentiment in that. Although I do not > think a docking framework is that complex, but maybe I'm wrong. > > And yes, ALMOST everyone is at ControlFX ;-) > > > >> Jonathan - why do you *cough* at ideas like more complex controls and >> docking frameworks? >> >> I think that a docking framework especially would be a great addition to >> JavaFX. >> >> Am I missing something? >> >>> On 7 Feb 2018, at 18:16, Jonathan Giles >>> wrote: >>> >>> Obviously everyone is at ControlsFX instead ;-) >>> >>> Part of the drop I would suggest is simply that many of the itches >>> people >>> want to scratch are now scratched. Alternatively, the remaining itches >>> are >>> either in more complex controls (*cough* docking frameworks *cough*) or >>> in >>> areas beneath the controls APIs - performance, webview, etc - which are >>> more challenging and require greater levels of dedication. >>> >>> However, more generally, your point is well made - contribution to >>> JavaFX >>> does not need to be synonymous with contribution to OpenJFX. People who >>> find the challenges of the current OpenJFX requirements too great should >>> be >>> encouraged to involve themselves in projects such as JFXtras, etc. >>> >>> -- Jonathan >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: Many years ago I had a discussion with Jonathan Giles about if the things that were being made in JFXtras would eventually become part of the JavaFX core. In the end I decided that, for me personally, I could do the things I wanted to perfectly in a separate project. The rigid structure that Java(FX) has to adhere to, would be a big downside. What I want to say with that is that all the external projects are also contributions to JavaFX. It does not matter whether for example a control is part of the core distribution or of a side project; it is just another module users can add to the mix. So reflecting back I still stand by that choice. But having a few more people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it forces me to deal with (and learn about) annoying stuff like Gradle build scripts and Java 9 migration. But because of that progress is not as fast as I would like it to be. Could it be that there is a decline in people willing to work for open source projects? Or is it just that this tech, JavaFX, is no longer appealing? Tom >>> Obviously everyone is at ControlsFX instead ;-) >>> >>> Part of the drop I would suggest is simply that many of the itches >>> people >>> want to scratch are now scratched. Alternatively, the remaining itches >>> are >>> either in more complex controls (*cough* docking frameworks *cough*) or >>> in >>> areas beneath the controls APIs - performance, webview, etc - which are >>> more challenging and require greater levels of dedication. >>> >>> However, more generally, your point is well made - contribution to >>> JavaFX >>> does not need to be synonymous with contribution to OpenJFX. People who >>> find the challenges of the current OpenJFX requirements too great should >>> be >>> encouraged to involve themselves in projects such as JFXtras, etc. >>> >>> -- Jonathan >>> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: Many years ago I had a discussion with Jonathan Giles about if the t
Re: More community participation in JavaFX
Jonathan - why do you *cough* at ideas like more complex controls and docking frameworks? I think that a docking framework especially would be a great addition to JavaFX. Am I missing something? > On 7 Feb 2018, at 18:16, Jonathan Giles wrote: > > Obviously everyone is at ControlsFX instead ;-) > > Part of the drop I would suggest is simply that many of the itches people > want to scratch are now scratched. Alternatively, the remaining itches are > either in more complex controls (*cough* docking frameworks *cough*) or in > areas beneath the controls APIs - performance, webview, etc - which are > more challenging and require greater levels of dedication. > > However, more generally, your point is well made - contribution to JavaFX > does not need to be synonymous with contribution to OpenJFX. People who > find the challenges of the current OpenJFX requirements too great should be > encouraged to involve themselves in projects such as JFXtras, etc. > > -- Jonathan > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >> >> Many years ago I had a discussion with Jonathan Giles about if the things >> that were being made in JFXtras would eventually become part of the JavaFX >> core. In the end I decided that, for me personally, I could do the things I >> wanted to perfectly in a separate project. The rigid structure that >> Java(FX) has to adhere to, would be a big downside. >> >> What I want to say with that is that all the external projects are also >> contributions to JavaFX. It does not matter whether for example a control >> is part of the core distribution or of a side project; it is just another >> module users can add to the mix. >> >> So reflecting back I still stand by that choice. But having a few more >> people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it >> forces me to deal with (and learn about) annoying stuff like Gradle build >> scripts and Java 9 migration. But because of that progress is not as fast >> as I would like it to be. Could it be that there is a decline in people >> willing to work for open source projects? Or is it just that this tech, >> JavaFX, is no longer appealing? >> >> Tom >> >> >> > Obviously everyone is at ControlsFX instead ;-) > > Part of the drop I would suggest is simply that many of the itches people > want to scratch are now scratched. Alternatively, the remaining itches are > either in more complex controls (*cough* docking frameworks *cough*) or in > areas beneath the controls APIs - performance, webview, etc - which are > more challenging and require greater levels of dedication. > > However, more generally, your point is well made - contribution to JavaFX > does not need to be synonymous with contribution to OpenJFX. People who > find the challenges of the current OpenJFX requirements too great should be > encouraged to involve themselves in projects such as JFXtras, etc. > > -- Jonathan > >> On Wed, Feb 7, 2018 at 3:05 PM, Tom Eugelink wrote: >> >> Many years ago I had a discussion with Jonathan Giles about if the things >> that were being made in JFXtras would eventually become part of the JavaFX >> core. In the end I decided that, for me personally, I could do the things I >> wanted to perfectly in a separate project. The rigid structure that >> Java(FX) has to adhere to, would be a big downside. >> >> What I want to say with that is that all the external projects are also >> contributions to JavaFX. It does not matter whether for example a control >> is part of the core distribution or of a side project; it is just another >> module users can add to the mix. >> >> So reflecting back I still stand by that choice. But having a few more >> people in the project (just like in JavaFX ;-) ) would be nice, but OTOH it >> forces me to deal with (and learn about) annoying stuff like Gradle build >> scripts and Java 9 migration. But because of that progress is not as fast >> as I would like it to be. Could it be that there is a decline in people >> willing to work for open source projects? Or is it just that this tech, >> JavaFX, is no longer appealing? >> >> Tom >> >> >> >>> On 7-2-2018 03:16, Kevin Rushforth wrote: >>> >>> I would recommend against having a separate issue tracker or mailing list >>> associated with the sandbox. That will create more confusion than any >>> benefit you might have. >>> >>> -- Kevin >>> >>> >>> Nir Lisker wrote: >>> Another thing to be careful about with the sandbox/staging idea is the confusion that will arise with duplication. There will be 2 issue trackers (JBS and GitHub (or GitHub-like)), 2 repo addresses, 2 wikis, and maybe 2 discussion lists. For those "in the know" this will be a simple matter, but for a potential contributor this can be a gamebreaker if not handled appropriately. Dalibor Topic's suggestion of contacting other mirrors can be instrumental in solving these problems. - Nir On Mon, Feb 5
Re: future content of OpenJFX
Thanks for confirming my “theory” :-) And just for clarity, I wasn’t referring to “observers” or “lurkers” in a derogatory fashion. In fact, it makes complete sense to only get involved when it enables you to make the most efficient use of your time. Who knows, the size of the “talent pool” may be much bigger than I thought, which would be great!!! > On 7 Feb 2018, at 07:49, John Neffenger wrote: > >> On 02/05/2018 08:14 PM, John-Val Rose wrote: >> ... is it possible that there are lots and lots of “observers” or “lurkers” >> out there just waiting until all the hard work of setting-up the physical >> and formal infrastructure to enable community contribution has been >> finalised before they’ll put their hands up? > > That's what this lurker is waiting for. :-) I really like the idea of having > a staging repository and an open issue tracker at either GitHub or Bitbucket > or GitLab. > > We'll find out how many people can contribute only after it's easy. > > John
Re: future content of OpenJFX
Maybe Kevin could request that anyone who is seriously both willing and capable to contribute to OpenJFX email him privately so that the list doesn’t get to “see” anyone who wants to fly under the radar. Kevin could then post the approximate number of resources actually available. I realise of course that some people may not wish to even let Kevin know of their interest and availability initially but at least we would have a ballpark figure as to the size of the “talent pool”. I think we need to have some handle on this number before any significant set-up work is undertaken (just in case the number is only 2 or 3 for example instead of 20 or so). > On 6 Feb 2018, at 22:12, Stephen Desofi wrote: > > A poll would definitely be useful because we may find ourselves another > subset. > > The subset of people who even want to go “off road” to begin with. Most > people only consider going places where the road already leads—and that might > be about 99%. > > > > Sent from my iPhone > >> On Feb 5, 2018, at 11:14 PM, John-Val Rose wrote: >> >> I think there’s a small matter that is being overlooked here. >> >> The size of the “talent pool”. >> >> I’m just pulling numbers out of thin air here but first I’m guessing that >> the vast majority of JavaFX users do *not* read this list. >> >> Then, out of those who do, only some *care* enough to contribute. >> >> Out of those, only some are *competent* enough to contribute. >> >> And then, out of that much smaller set, only an even smaller subset are in a >> situation that *permits* them to contribute, either because they have >> well-paid jobs and a bit of spare time or they really need a feature added >> for their own use. >> >> Given that I don’t know what the “starting” number is (the total number of >> JavaFX users) and neither do I know what fraction to apply to each smaller >> subset, the end result (the talent pool) is potentially only a handful of >> people. >> >> I’m simply mentioning this because in every discussion we have here >> regarding innovation, community participation or plans for new features, it >> looks like the same group of people get involved - and it’s not exactly a >> “crowd”. >> >> Does this mean that we don’t have a “critical mass” or is it possible that >> there are lots and lots of “observers” or “lurkers” out there just waiting >> until all the hard work of setting-up the physical and formal infrastructure >> to enable community contribution has been finalised before they’ll put their >> hands up? >> >> Maybe we could take a poll to see how many members of the community would be >> willing AND able to contribute, knowing that they may not necessarily end up >> working on features they are interested in AND who are prepared for their >> contribution itself & the value it adds to JavaFX to be their only tangible >> reward? >> >>> On 6 Feb 2018, at 11:23, Stephen Desofi wrote: >>> >>> Hi Johan, >>> >>>I read the article you linked to >>> (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some >>> very good points indeed. >>> >>> I also spent a little time thinking over your list of interests: >>> * more alignment with mobile >>> * a clean and lean low-level rendering pipeline API that would allow easier >>> plugability with upcoming low-level rendering systems >>> * extensions for Chart API >>> >>> Those would be high on my list as well, but there is something else I'd >>> like to throw into the equation. >>> >>> If somebody can contribute money to fund the development of their wishlist, >>> fine, that's the easy part, but asking people to contribute time is a bit >>> more complicated. For example, I may want "more alignment with mobile", >>> but I may be better qualified to contribute "extensions for the Chart API" >>> even though that isn't my primary motivator. >>> >>> Often the reason we want something is because we haven't the skills to do >>> it ourself, but we have skills to do other things. How can situations such >>> as this be factored into the equation? It seems like we need a way to >>> "trade". >>> >>> Steve >>> >>> >>> >>> Sent from iCloud >>> >>> On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: >>> >>> In order to separate the "What" from the &qu
Re: future content of OpenJFX
Yes - I agree. WASM would be great. And I believe the folks at JPro are working on just that... > On 6 Feb 2018, at 22:01, Stephen Desofi wrote: > > Another one high on my list would be browser support via WebAssembly. > Access to the DOM would be secondary, or not important at all. If we had the > ability to draw then we don’t need the DOM. IMHO. > > > Sent from my iPhone > >> On Feb 6, 2018, at 4:00 AM, Paul Ray Russell wrote: >> >> +1 >> >> * more alignment with mobile >> * a clean and lean low-level rendering pipeline API that would allow easier >> plugability with upcoming low-level rendering systems >> >> I would like to add a higher level desire >> >> * a consensus that JavaFX will continue to open itself more to integration. >> It has a rumour for being closed to integration. I recall the folks at JOGL >> concluded this when they tried to integrate, but mostly, I have in mind the >> might of JMagick, which could be easily integrated to provide all the image >> manipulation that JavaFX so lacks currently. >> >> Perhaps a forum poll would ease a vote?
Re: future content of OpenJFX
I think there’s a small matter that is being overlooked here. The size of the “talent pool”. I’m just pulling numbers out of thin air here but first I’m guessing that the vast majority of JavaFX users do *not* read this list. Then, out of those who do, only some *care* enough to contribute. Out of those, only some are *competent* enough to contribute. And then, out of that much smaller set, only an even smaller subset are in a situation that *permits* them to contribute, either because they have well-paid jobs and a bit of spare time or they really need a feature added for their own use. Given that I don’t know what the “starting” number is (the total number of JavaFX users) and neither do I know what fraction to apply to each smaller subset, the end result (the talent pool) is potentially only a handful of people. I’m simply mentioning this because in every discussion we have here regarding innovation, community participation or plans for new features, it looks like the same group of people get involved - and it’s not exactly a “crowd”. Does this mean that we don’t have a “critical mass” or is it possible that there are lots and lots of “observers” or “lurkers” out there just waiting until all the hard work of setting-up the physical and formal infrastructure to enable community contribution has been finalised before they’ll put their hands up? Maybe we could take a poll to see how many members of the community would be willing AND able to contribute, knowing that they may not necessarily end up working on features they are interested in AND who are prepared for their contribution itself & the value it adds to JavaFX to be their only tangible reward? > On 6 Feb 2018, at 11:23, Stephen Desofi wrote: > > Hi Johan, > > I read the article you linked to > (http://www.tomitribe.com/blog/2013/11/feed-the-fish/) and it raises some > very good points indeed. > > I also spent a little time thinking over your list of interests: > * more alignment with mobile > * a clean and lean low-level rendering pipeline API that would allow easier > plugability with upcoming low-level rendering systems > * extensions for Chart API > > Those would be high on my list as well, but there is something else I'd like > to throw into the equation. > > If somebody can contribute money to fund the development of their wishlist, > fine, that's the easy part, but asking people to contribute time is a bit > more complicated. For example, I may want "more alignment with mobile", but > I may be better qualified to contribute "extensions for the Chart API" even > though that isn't my primary motivator. > > Often the reason we want something is because we haven't the skills to do it > ourself, but we have skills to do other things. How can situations such as > this be factored into the equation? It seems like we need a way to "trade". > > > Steve > > > > Sent from iCloud > > On Feb 05, 2018, at 12:07 PM, Johan Vos wrote: > > In order to separate the "What" from the "How" (discussed in another > thread), I would like to start a discussion about what people think should > be considered for future JavaFX work. > > I'd like to start with what I think is an important note on the context. > If I want feature X in JavaFX, I ask myself two questions: > 1. Do I want to contribute time and do it (at least for a large part) > myself? > 2. Do I want to spend money on it? > > If that sounds too economic or commercial, I recommend reading the > excellent blog entry by David Blevins about funding Java EE development > (more than 4 years old and still very relevant): > http://www.tomitribe.com/blog/2013/11/feed-the-fish/ > > Actually, this is a model we've been using at Gluon for a number of > customers. When people ask us about a specific feature, we ask if they are > willing to pay us for the development, AND if they are ok with us donating > it back to an open-source initiative (e.g. OpenJFX, but also ControlsFX, > JavaFXports, Gluon Charm Down, Gluon Maps,...). > As a consequence, the features we are working on are all relevant to (at > least a part of) the industry. Some companies doubt there is business value > in JavaFX, we prove the opposite while making the Open Source community > better. > > I think by now it should be clear to all that there is no free lunch > (anymore). If your business depends on a feature being added to JavaFX, how > much (time/money) are you willing to contribute? If the answer is > "nothing", you can still hope that others want to do it, and in many cases > that will eventually happen -- but you don't control the timeline. > > This principle is a bit a simplification though. In many practical cases, > people want to have feature X and are willing to contribute "something" > (e.g. they want to work on it in spare-time, or fund 20% of a developer) > but not enough to do everything. > I think in this case it's a matter of gathering enough interest in this
Re: More community participation in JavaFX
Yes, me too. I think it’s logical to establish *how* to make contributions first (and it’s great to see a lot of progress with this so far) but then there clearly needs to be a discussion of exactly *what* those contributions are, who decides which ones are important or permitted and how are they prioritised. I have no experience in the “how” aspect of all this but I certainly have a large “wish list” of potential contributions :-) > On 6 Feb 2018, at 01:48, Paul Ray Russell wrote: > > "I think a discussion on "where we should take the platform" is a good > one to have...just not as part of this thread. " > > I'm looking forwards to the new thread :)
Re: More community participation in JavaFX
Well, if your interest is mainly in the future “cross platform king” of languages, you might just want to have a look at Kotlin and Kotlin/Native. Oh, and I have heard you can develop JavaFX apps with Kotlin too! > On 4 Feb 2018, at 13:37, Stephen Desofi wrote: > > Yes, probably me. > > Sent from iCloud > >> On Feb 03, 2018, at 09:35 PM, John-Val Rose wrote: >> > >> Well, then one of us is "off topic"... >> >> >> Kevin Rushforth: >> >> "We are specifically looking to discuss ideas around the following areas: >> * Easing barriers to contribution (e.g., making JavaFX easier to build, >> better documentation, making it easier to test changes) >> * Code review policies >> * API / feature review policies >> * Code review tools (we currently use webrev, but that isn't set in stone)" >> >>> On 4 February 2018 at 13:29, Stephen Desofi wrote: >> >>> John, >>> >>> I think you and I are thinking on two different levels.You are >>> talking about the mechanics of making contributing to JavaFX easier.I >>> am talking about making the motivations of contributing to JavaFX easier. >>> >>> Steve >>> >>> Sent from iCloud >>> >>>> On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: >>>> >>> >>>> Stephen, >>>> >>>> 1. Swift and your "crystal ball" view of its spectacular success in the >>>> future has nothing whatsoever to do with making contributing to JavaFX >>>> easier. >>>> >>>> 2. Like everyone else who already wants to contribute to JavaFX, we don't >>>> need someone to provide us with "a compelling story as to why developers >>>> should join and contribute". >>>> >>>> 3. TL;DR >>>> >>>> John-Val Rose (trying to be polite) >>>> >>>>> On 4 February 2018 at 12:58, Stephen Desofi wrote: >>>>> John, >>>>> >>>>> The point I am making is that Swift is catching up as a cross >>>>> platform toolkit and is available on: >>>>> >>>>> Mac and iOS, (Full Support) >>>>> https://www.swift.org >>>>> >>>>> Android (early) >>>>> https://academy.realm.io/posts/swift-on-android/ >>>>> >>>>> Linux: (early) >>>>> >>>>> https://itsfoss.com/use-swift-linux/ >>>>> >>>>> Windows: (early) >>>>> >>>>> https://www.infoworld.com/article/3067364/open-source-tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >>>>> >>>>> >>>>> Browser: (very Preliminary) >>>>> >>>>> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >>>>> >>>>> Server Side: (Mac and Linux) >>>>> https://www.swift.org >>>>> >>>>> >>>>> So my point is that soon Swift will steal the Cross Platform Mantra from >>>>> Java. It is happening very quickly and Swift has great graphics and >>>>> gaming capabilities as well. >>>>> >>>>> Why would a new developer start with Java?If we are looking 10 years >>>>> out, I think Apple is coming head on. >>>>> >>>>> Also when you say this thread is about the ease with which the community >>>>> can contribute to JavaFX, it begs the question "what kinds of >>>>> contribution?".Are we here to push the platform forward and >>>>> contribute new ideas or just do bug fixes? >>>>> >>>>> Swift is a real threat to Java being the cross platform development King. >>>>>Java can hold on to that story for only a couple more years. It >>>>> surely won't last. >>>>> >>>>> Dart also runs on Android and iOS via Flutter, has Server side Dart >>>>> option, runs in the Browser very well today with full support for SVG and >>>>> Canvas -- and if WebGPU becomes a Web standard, Google will most >>>>> certainly support it. >>>>> >>>>> Looking toward the future, if Java doesn't run in the browser, doesn't >>>>> support games on any platform, and only works on iOS and Android via >>>
Re: More community participation in JavaFX
Well, then one of us is "off topic"... Kevin Rushforth: "We are specifically looking to discuss ideas around the following areas: * Easing barriers to contribution (e.g., making JavaFX easier to build, better documentation, making it easier to test changes) * Code review policies * API / feature review policies * Code review tools (we currently use webrev, but that isn't set in stone)" On 4 February 2018 at 13:29, Stephen Desofi wrote: > John, > > I think you and I are thinking on two different levels.You are > talking about the mechanics of making contributing to JavaFX easier.I > am talking about making the motivations of contributing to JavaFX easier. > > Steve > > Sent from iCloud > > On Feb 03, 2018, at 09:14 PM, John-Val Rose wrote: > > Stephen, > > 1. Swift and your "crystal ball" view of its spectacular success in the > future has nothing whatsoever to do with making contributing to JavaFX > easier. > > 2. Like everyone else who already wants to contribute to JavaFX, we don't > need someone to provide us with "a compelling story as to why developers > should join and contribute". > > 3. TL;DR > > John-Val Rose > (trying to be polite) > > On 4 February 2018 at 12:58, Stephen Desofi wrote: > >> John, >> >> The point I am making is that Swift is catching up as a cross >> platform toolkit and is available on: >> >> Mac and iOS, (Full Support) >> https://www.swift.org <https://swift.org> >> >> Android (early) >> >> https://academy.realm.io/posts/swift-on-android/ >> >> >> Linux: (early) >> >> >> https://itsfoss.com/use-swift-linux/ >> >> >> Windows: (early) >> >> >> https://www.infoworld.com/article/3067364/open-source-tools/ >> swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html >> >> >> >> Browser: (very Preliminary) >> >> >> <https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly> >> https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly >> >> Server Side: (Mac and Linux) >> https://www.swift.org <https://swift.org/> >> >> >> So my point is that soon Swift will steal the Cross Platform Mantra from >> Java. It is happening very quickly and Swift has great graphics and >> gaming capabilities as well. >> >> >> Why would a new developer start with Java?If we are looking 10 years >> out, I think Apple is coming head on. >> >> >> Also when you say this thread is about the ease with which the community >> can contribute to JavaFX, it begs the question "what kinds of >> contribution?".Are we here to push the platform forward and contribute >> new ideas or just do bug fixes? >> >> >> Swift is a real threat to Java being the cross platform development King. >>Java can hold on to that story for only a couple more years. It surely >> won't last. >> >> >> Dart also runs on Android and iOS via Flutter, has Server side Dart >> option, runs in the Browser very well today with full support for SVG and >> Canvas -- and if WebGPU becomes a Web standard, Google will most certainly >> support it. >> >> >> Looking toward the future, if Java doesn't run in the browser, doesn't >> support games on any platform, and only works on iOS and Android via Gluon >> VM, and does it with only limited graphics capability, then I think >> JavaFX will be a tough sell in the future. Even tougher than it is today. >> >> >> If the point of the discussion is to build the developer community, I >> think we first need a compelling story as to why developers should join and >> contribute. >> >> >> The fact that I am using Dart and JavaFX, and I am seriously >> considering if I should switch to Dart everywhere, or to Dart and Swift >> (instead of Dart and FX) means JavaFX doesn't have the lead we think it >> does.I love JavaFX and would love to contribute, but it's hard when I >> myself am looking at other options mainly because I also want my software >> to be here 10 years from now, and I am seriously questioning if JavaFX will >> keep up. >> >> >> I think there is a small window of opportunity for JavaFX to make a stand >> before it is permanently relegated to a Server side language. This cross >> platform story won't fly too much longer, especially when Swift starts to >> run everywhere and in the browser too, and if Google d
Re: More community participation in JavaFX
Stephen, 1. Swift and your "crystal ball" view of its spectacular success in the future has nothing whatsoever to do with making contributing to JavaFX easier. 2. Like everyone else who already wants to contribute to JavaFX, we don't need someone to provide us with "a compelling story as to why developers should join and contribute". 3. TL;DR John-Val Rose (trying to be polite) On 4 February 2018 at 12:58, Stephen Desofi wrote: > John, > > The point I am making is that Swift is catching up as a cross > platform toolkit and is available on: > > Mac and iOS, (Full Support) > https://www.swift.org <https://swift.org> > > Android (early) > > https://academy.realm.io/posts/swift-on-android/ > > > Linux: (early) > > https://itsfoss.com/use-swift-linux/ > > > Windows: (early) > > https://www.infoworld.com/article/3067364/open-source- > tools/swift-for-windows-arrives-at-last-but-as-an-unofficial-port.html > > > > Browser: (very Preliminary) > > <https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly> > https://stackoverflow.com/questions/46572144/compile-swift-to-webassembly > > Server Side: (Mac and Linux) > https://www.swift.org <https://swift.org/> > > > So my point is that soon Swift will steal the Cross Platform Mantra from > Java. It is happening very quickly and Swift has great graphics and > gaming capabilities as well. > > > Why would a new developer start with Java?If we are looking 10 years > out, I think Apple is coming head on. > > > Also when you say this thread is about the ease with which the community > can contribute to JavaFX, it begs the question "what kinds of > contribution?".Are we here to push the platform forward and contribute > new ideas or just do bug fixes? > > > Swift is a real threat to Java being the cross platform development King. >Java can hold on to that story for only a couple more years. It surely > won't last. > > > Dart also runs on Android and iOS via Flutter, has Server side Dart > option, runs in the Browser very well today with full support for SVG and > Canvas -- and if WebGPU becomes a Web standard, Google will most certainly > support it. > > > Looking toward the future, if Java doesn't run in the browser, doesn't > support games on any platform, and only works on iOS and Android via Gluon > VM, and does it with only limited graphics capability, then I think > JavaFX will be a tough sell in the future. Even tougher than it is today. > > > If the point of the discussion is to build the developer community, I > think we first need a compelling story as to why developers should join and > contribute. > > > The fact that I am using Dart and JavaFX, and I am seriously > considering if I should switch to Dart everywhere, or to Dart and Swift > (instead of Dart and FX) means JavaFX doesn't have the lead we think it > does.I love JavaFX and would love to contribute, but it's hard when I > myself am looking at other options mainly because I also want my software > to be here 10 years from now, and I am seriously questioning if JavaFX will > keep up. > > > I think there is a small window of opportunity for JavaFX to make a stand > before it is permanently relegated to a Server side language. This cross > platform story won't fly too much longer, especially when Swift starts to > run everywhere and in the browser too, and if Google does the same thing > with Dart, and they both support games, where will Java be? > > > If we are looking 10 years out then surely this will happen. The big > question is what will we do, and where will JavaFX be? > > > Steve Desofi > > > > > On Feb 03, 2018, at 03:09 PM, John-Val Rose wrote: > > > Stephen - I’m not quite following you. > > This thread is about improving the ease with which the community can > contribute to JavaFX. > > I see no point in comparing JavaFX (a cross platform graphics toolkit for > JVM languages) with a Swift (a general purpose programming language that > runs on Apple hardware). > > On 4 Feb 2018, at 00:18, Stephen Desofi wrote: > > This begs the question, why has the bar been set too low? I am new to > this community and don’t know much history other than a couple weeks of bug > fix messages flying by. > > I am not even clear of what our role and purpose is supposed to be. Are > we here for only bug fixes, and follow the direction and flow that is > already set, or as contributors would we be allowed to contribute to the > goals and direction of JavaFX? > > FX is a good platform with great potential, but it bigges
Re: More community participation in JavaFX
Stephen - I’m not quite following you. This thread is about improving the ease with which the community can contribute to JavaFX. I see no point in comparing JavaFX (a cross platform graphics toolkit for JVM languages) with a Swift (a general purpose programming language that runs on Apple hardware). > On 4 Feb 2018, at 00:18, Stephen Desofi wrote: > > This begs the question, why has the bar been set too low? I am new to this > community and don’t know much history other than a couple weeks of bug fix > messages flying by. > > I am not even clear of what our role and purpose is supposed to be. Are we > here for only bug fixes, and follow the direction and flow that is already > set, or as contributors would we be allowed to contribute to the goals and > direction of JavaFX? > > FX is a good platform with great potential, but it biggest deficiency is > “mind share”. People don’t see too many real world accomplishments that > knock your socks off. Most people use web and phone to run apps. PC and > Desktop apps are a small part of the market. > > Gluon has just recently released gluon VM and Gluon Mobile to allow FX on > phones and tablets. > > The problem I see is once I can use FX on phones how will it compete with > Swift? > > True that “write once, run everywhere” is important and Java has a lead over > Swift. But Swift has a lead on capability. > > In the end Swift will catch up with Java in the “write once, run anywhere” > mantra. Will FX catch up with Swift in graphics by then? > > Java has a lead in many areas, but if we look 10 years out, it seems clear to > me that Java needs to raise the bar or face extinction as a client side > development platform or forever be confined to the server. > > This is why I need some clarification as to what our role as contributors is > going to be. I don’t believe an open source project can flourish if the > contributors have no say or stake in the direction. > > Steve Desofi > > > > > > Sent from my iPhone > >> On Feb 2, 2018, at 11:55 PM, John-Val Rose wrote: >> >> I think Kevin outlined in his opening post what would be considered "out of >> scope". >> >> However, I agree with you on the basic premise that, in general, the bar has >> been set way too low as to the potential use cases and performance of >> JavaFX. In fact, I firmly believe that games & complex visualisations etc. >> *should* be possible with JavaFX given that most of the heavy lifting is >> being done by the GPU. It's just that, at the moment, the scene graph >> rendering pipeline is significantly slower than it could be and it is for >> this reason that we don't find applications using advanced 3D graphics & >> animations etc. (like we see in games) being built with JavaFX. It's just >> not possible when the node count reaches even a very small threshold. >> >> This is a topic I have tried to discuss numerous times and also believe that >> I can improve the performance of the scene graph rendering in a very >> tangible way. >> >> If things pan-out as they are being described and becoming & being a >> contributor is simplified to the extent where it justifies me devoting a >> large chunk of my time to OpenJFX, this is probably what I would want to >> work on first. >> >> Graciously, >> >> John-Val Rose >> >>> On 3 February 2018 at 14:07, Stephen Desofi wrote: >>> I don’t understand why discussing new graphics capabilities such as gaming >>> or WebGPU, etc is so off limits. Can you explain that? >>> >>> Steve Desofi >>> >>> Sent from my iPhone >>> >>> > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth >>> > wrote: >>> > >>> > Looks like we have some good discussion so far. >>> > >>> > I see a few themes emerging (build/test, sandbox on GitHub, ease of >>> > filing bugs, etc) along with some discussion on graphics performance >>> > (which is fine as long as the discussion doesn't veer too far into >>> > discussing specific graphics features). >>> > >>> > I'll let more folks chime in before I reply to anything specifically (and >>> > I'll be offline over the weekend anyway). >>> > >>> > Thanks! >>> > >>> > -- Kevin >>> > >>
Re: More community participation in JavaFX
I think Kevin outlined in his opening post what would be considered "out of scope". However, I agree with you on the basic premise that, in general, the bar has been set way too low as to the potential use cases and performance of JavaFX. In fact, I firmly believe that games & complex visualisations etc. *should* be possible with JavaFX given that most of the heavy lifting is being done by the GPU. It's just that, at the moment, the scene graph rendering pipeline is significantly slower than it could be and it is for this reason that we don't find applications using advanced 3D graphics & animations etc. (like we see in games) being built with JavaFX. It's just not possible when the node count reaches even a very small threshold. This is a topic I have tried to discuss numerous times and also believe that I can improve the performance of the scene graph rendering in a very tangible way. If things pan-out as they are being described and becoming & being a contributor is simplified to the extent where it justifies me devoting a large chunk of my time to OpenJFX, this is probably what I would want to work on first. Graciously, John-Val Rose On 3 February 2018 at 14:07, Stephen Desofi wrote: > I don’t understand why discussing new graphics capabilities such as gaming > or WebGPU, etc is so off limits. Can you explain that? > > Steve Desofi > > Sent from my iPhone > > > On Feb 2, 2018, at 8:51 PM, Kevin Rushforth > wrote: > > > > Looks like we have some good discussion so far. > > > > I see a few themes emerging (build/test, sandbox on GitHub, ease of > filing bugs, etc) along with some discussion on graphics performance (which > is fine as long as the discussion doesn't veer too far into discussing > specific graphics features). > > > > I'll let more folks chime in before I reply to anything specifically > (and I'll be offline over the weekend anyway). > > > > Thanks! > > > > -- Kevin > > >
Re: More community participation in JavaFX
Kevin - thanks so much for this extremely well thought-out, informative and positive email. It’s the best post I’ve ever seen from Oracle on this list! It clearly highlights 2 things: 1. The future of JavaFX is heavily reliant on community involvement. 2. Oracle are actually listening to community concerns and are actively trying to address the main issues raised. I’ve never doubted the enthusiasm or expertise of the “small” Oracle JavaFX team and I’m sure if Larry came downstairs and said “Hey Kevin, would you like another 50 devs on your team?”, your answer would probably be “Sure, but 100 would be even better!”. But, we know you must work within the resourcing and financial constraints that prevail. So, I for one have been very keen to contribute to OpenJFX, have suggested several innovative features and have tried to devote at least some of my own very limited time to achieving this, only to be met with a few major barricades. It has been noted that the most fundamental aspect of development (i.e. building the project from source) is currently a significant challenge on all platforms and having to attempt to decipher errors and get the builds to work reliably is in itself enough to put off many potential contributors (perhaps permanently). So, I’m very pleased to see that this issue has been prioritised - thank you. Another barricade is the complexity of the formal process of making contributions and the extensive “red tape” which I see you are also addressing. I’m willing to bet that once the community can build OpenJFX on any platform reliably, quickly and in a repeatable manner, a large increase in the number of people who actually *do* contribute will follow. It is well known that one of the real strengths of JavaFX is the vibrant and passionate community. These proposals give us all a much better chance to become tangible contributors and for JavaFX to not just continue to “exist” but for real innovation and progress to occur. It’s somewhat ironic that I have been discussing setting up and maintaining a mirror build with some devs privately which could act as a sandbox or incubation platform so I’m very pleased to know that the large amount of effort that would have entailed is mostly going to be addressed through these proposals. These are now exciting times for JavaFX! I foresee the fusion of Oracle expertise and stewardship with community passion and skills and the great result for everyone being a living, breathing and thriving OpenJFX :-) Thanks again for putting the time and effort into these awesome proposals and I hope that many “lurkers” will step up and together we can build something of tremendous quality, utility and value! Graciously, John-Val Rose > On 2 Feb 2018, at 11:03, Richard Steiger wrote: > > Hi Kevin, > > As a long-time observer of the OpenJFX project, let me put all my chips at > this point on making builds more stable, bullet-proof, and automated, and > give equal weight making them so on Win10 and OS/X, specifically, the same > weight as is given to making building and developing on Linux work well. > > Over the last 3 or so years, on at least 3 separate occasions, I've gotten a > head of inspirational steam to try-out some new features (the latest being > using byte-code engineering to radically streamline binding, rendering most > of the current API obsolete, and hugely improving performance). I then > attempt to build the whole project from sources (not always required, but > essential when it is) on Win10, my development platform of choice, and > invariably get wound around the axel of no-longer published VS tooling, > missing binaries, and other show-stopper glitches. > > Like many potential contributors, I've got a day job, plus am trying to > launch a garage startup, so my time is a very scarce resource. I simply > don't have the extra cycles to troubleshoot highly convoluted builds (of > which OpenJFX is one of the worst I've seen), so my head of steam bleeds-off > for another year or so. Nor am I willing to switch to a Linux development > environment, remap my motor memory, take-on care and feeding of another > platform (Windows and OS/X suck enough time, and are essential for my > business). Every time I've hit this wall, I've puzzled over how the team has > tolerated the situation, and moved on. > > So, to be redundant, all the other issues you've so cogently enumerated pale > in the face of development portability, starting with build stability and > cleanliness on widely-used platforms. > > Thanks for considering the above input. > > -rjs > > >> On 2/1/18 3:26 PM, Kevin Rushforth wrote: >> To: OpenJFX Developers >> >> We are looking to grow the community of contributors to the OpenJFX project, >> especiall
Re: Innovation again
Thank you Pedro. I’ve admired your work for some time. Well, it seems we’re all singing the same song. The question is, who (if anyone) is listening? > On 19 Dec 2017, at 09:12, Pedro Duque Vieira > wrote: > > Hi, > > I've been with JavaFX since version 1, also have experience with Swing. > Been on a number of JavaFX commercial projects, contributed to community > projects like JFxtras, ControlsFX, worked on Scene Builder and also have > some open source JavaFX projects of my own. > > Like others said I think building openJFX should be as easy as possible, > having to climb a mountain to be able to contribute or worse yet trying to > climb and having to give up half way will block many people from > contributing. > > Having JavaFX team members help out contributors would also be very > helpful, I think, or at least having the OpenJFX various areas thoroughly > documented. For every hour a JavaFX team member spends on helping out with > some guidance community members on a specific issue it would be multiplied > for several working man hours. > I remember when I was a kid reading about how it was important for the guys > who made Counter-Strike to be able to talk to Valve developers directly, > Counter-Strike is one of the most successful online games of all time, it > started as a modification (mod) to the Half-Life game owned by Valve, it > was a free modification and was developed by a bunch of passionate > developers who earned nothing for it in return. > The game was created 18 years ago, later Valve adquierd the rights and > now, 18 years later Valve still sells and profits from newer versions of > the Game. A bunch of other successful mods were also created for Half-Life. > > Lastly someone has mentioned performance as the major issue with JavaFX. I > agree. I've never felt this with desktop apps, but maybe the apps I've > built were not performance heavy. > Having worked on JavaFX for mobile the major issue I've found with it was > performance, specially animations were not smooth which hindered the user > experience. If JavaFX is to grow and get more and more adoption it has to > run great on mobile. > > My 0.02€ :) > > Cheers, > > > > -- > Pedro Duque Vieira
Re: Innovation “essay”
It’s been noted that my previous email was very much in the “TL;DR” category. I’m sorry about that. I guess I just had a lot to say and feel very passionate about JavaFX. Graciously, John-Val Rose
Re: Innovation again (was Re: Text classes)
first-class graphics toolkit so all of us who love Java and who eat, breathe & live Java don't have to "turn to the dark side" and learn or relearn languages like C++ or (dare I say it) C# (aka "Microsoft Java"). We can observe what is happening with other toolkits and also keep our fingers on the pulse of graphics toolkit technology directions/advancements in general and use these as inspirations for how we decide to enhance JavaFX. I think I was probably wrong or at least misguided to think that we need to try to make JavaFX "a Java version of Qt" for example. Perhaps we just need JavaFX to meet the major requirements of Java GUI developers and be able to use it to produce *modern* commercial applications that look great, work well and hold their own against other products, all the while we are not having to drift away from Java or the JVM. So to summarise (while you are hopefully still awake), I am not suggesting that I try to tell others what to do or what JavaFX should or shouldn't be but rather that I am simply offering to be the central contact who coordinates the ideas, the efforts and the team in general and also to act as a liaison with Oracle or any other company that can be involved. I can also try to set-up any infrastructure required such as a website, a mailing list, Google group, GitHub project etc. If the community feels I am not the best person for this role then that's perfectly OK! I am more than happy to just to burn the midnight oil and contribute in any way I can. After all, this is not about "me" at all - it's all about JavaFX. I strongly suspect that such luminaries as mentioned by Chris (and Chris himself) are light years ahead of me in knowledge and skills with both Java and JavaFX (and they are all my heroes!). Maybe if I can find an eye patch I can be Nick Fury and the others can be The Avengers? (Sorry if you're more of a DC fan). Please feel free to reach out to me at any time to (privately and confidentially) discuss any of these issues, or even better, post on this list. P.S. I'd like to especially praise the efforts and outstanding achievements of Johan Vos and Gluon. All JavaFX developers owe them enormous gratitude. And, they are already doing much of what I am proposing (though mainly in the mobile space). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 15 December 2017 at 18:26, Chris Newland wrote: > Hi John, > > Here's my $0.02 on JavaFX as someone who's used it for over 4 years in the > JITWatch project (https://github.com/AdoptOpenJDK/jitwatch) and also for > fun with my DemoFX benchmarks (https://github.com/chriswhocodes/DemoFX). > > On the whole I think the API is very good. Event handling, layout, choice > of components give me 99% of what I need. > > The CSS approach to styling feels a bit clunky when I want to change > fine-grained appearance programatically without defining new CSS classes. > Proper font metrics would be nice too (already discussed recently). > > The Canvas/GraphicsContext API provides a decent entry point into "old > school" 2D programming and a way to avoid the scenegraph which does suffer > with scale when you push it too hard. You can do fun things with > PixelReader/Writer. > > Personally I'd like an even lower level API to framebuffers as the current > implementation looks a bit copy-heavy (my opinion from just the source > code, I've not had time to see how much the JIT saves us here). I'd really > like the video frame grabber API for MediaPlayer (deprecated after 8) > added back but I'm probably alone here. I can always go off-heap here or > just implement a video decoder in pure Java. > > For 3D I think a component that provides a surface usable by an existing > OpenGL library is probably better than trying to replicate in pure OpenJFX > but this isn't really my area. > > I was disappointed when Oracle decided to drop support for ARM / IoT but > that's no reflection on the JavaFX team, just a commercial decision by a > cloud-focused company. I've tried to keep IoT support going via community > builds of JavaFX 8 at https://www.chriswhocodes.com but I never really > cracked getting Windows builds working. I'm hoping to find some time next > year to work with the AdoptOpenJDK group (CC'd) and Laurent Borges > (Marlin/MarlinFX) to improve early access testing and cross-platform > support of OpenJFX builds. This got a lot harder since the modular JDK9 > where you can no longer simply modify OpenJFX, rebuild, and drop an > overlay onto your JRE. > > There are a few companies doing great work (Canoo, Gluon etc.) and a long > list of community individuals (Gerrit, Carl, Sean, Almas, Johan, Alessio, > Sven, Andres, Dirk, Dierk,
Re: Innovation again (was Re: Text classes)
I posted this over a week ago: > I am willing to work with *anyone* (within Oracle or not) on the features that the community craves, > such as those I listed (and any others). Not just because “many hands make light work” but because > I don’t know everything (or even close) and I need the knowledge and skills of others to assist me. Not > to mention that I have only 24 hours in a day like everyone else and, also like everyone else, some of > that time has to be devoted to earning an income. > > So, if there’s anyone reading this who has the time, the skills, the commitment and the passion to work hard (in your own time) to get these tasks done then please contact me privately. To my significant disappointment, only one person has contacted me since then in relation to this proposal. I'm beginning to think that I am completely out of touch with the JavaFX community, what they actually want and also with exactly *what* JavaFX is or is meant to be. I have reached out on this list and via Twitter in the hope that an inspired and passionate group of developers could come together, pool their resources and collaborate on taking JavaFX as far is it can possibly go as a fully-fledged hardware-accelerated graphics toolkit for the JVM. But... it seem that my "vision" for JavaFX is unique to me and I have to say that I really don't understand why that is. Is it that the JavaFX community see it as merely a Swing replacement or "upgrade" and that there just aren't people out there who want to do more sophisticated things with a Java-based toolkit or at least see performance increase dramatically? Or, do people feel that the kind of features you can find in say Qt cannot be added to JavaFX because it's a "Java thing": well all know how slow Java is and that if you want to do real animations, visualisations etc. then you have to use C++? Well, it's not the 1990s anymore. Java is NOT the problem. So, what IS the problem? I have to say that as chief architect for my company, if the JavaFX community (and I include Oracle as a big part of that) simply don't want to see innovation in JavaFX, won't support or contribute to making it happen or feel they don't need it, causing JavaFX to lag further and further behind other graphic toolkits and never be capable of supporting such features as advanced animations, visualisations, games, 3D, VR, AR and have proper HTML5 support etc. then, despite being a huge Java fan and advocate, JavaFX simply can't even be on the table of technologies to choose from when I'm developing a technological strategy. So, I'd like to ask this multi-part question in the hope that as many people reply as possible: *** For *your* siutation, what is JavaFX, how do you want it to evolve and what does it mean to you? *** Maybe I really am "Robinson Crusoe"... Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 6 December 2017 at 17:16, John-Val Rose wrote: > Absolutely - there needs to be a viable community that is not just Oracle. > > So, is there one? If not, how do we build one? > > OK, so let me rephrase my earlier email: > > I am willing to work with *anyone* (within Oracle or not) on the features > that the community craves, such as those I listed (and any others). Not > just because “many hands make light work” but because I don’t know > everything (or even close) and I need the knowledge and skills of others to > assist me. Not to mention that I have only 24 hours in a day like everyone > else and, also like everyone else, some of that time has to be devoted to > earning an income. > > So, if there’s anyone reading this who has the time, the skills, the > commitment and the passion to work hard (in your own time) to get these > tasks done then please contact me privately. > > > On 6 Dec 2017, at 16:50, Philip Race wrote: > > > > There needs to be a viable community that is not just Oracle to support > you here .. > > I think everyone has come to be dependent on Oracle to "be there". > > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > > > -phil. > > > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: > >> Well, that’s all fine but you didn’t address the issue of working with > someone within Oracle to get these innovations done. > >> > >> Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > >> > >> I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > >> > >>> On
Re: Innovation again (was Re: Text classes)
Yes, I obviously need to know if anything I work on or design is going to be accepted or is even wanted by the community as a whole, and as early on in the process as possible. Heck, if I had my way, JavaFX would be used to build everything from forms to FPS games and highly complex and performant 3D visualizations. And don't say it can't be done in Java - it can. JavaMonkeyEngine can be used to create awesome games (for example). Plus, I have never "done" a JEP but I believe it's quite a long and involved process (?) So, I would appreciate some clarification on the best process and steps to take to go from ideas to released features. Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology On 6 December 2017 at 19:33, Markus KARG wrote: > Yes, but not everything needs a JEP always. Maybe what Phil has in mind is > small enough to be accepted without. Somebody has to decide before filing > the JEP. > > -Markus > > > > From: Mario Torre [mailto:neugens.limasoftw...@gmail.com] > Sent: Mittwoch, 6. Dezember 2017 09:11 > To: Markus KARG > Cc: openjfx-dev@openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > > > I think Phil said that, the way to propose such changes is to file a Jep > and discuss it here. > > > > Cheers, > > Mario > > > > On Wed 6. Dec 2017 at 09:07, Markus KARG wrote: > > I think what John actually asked for is whom to send his design upfront at > the JFX team to get an initial judgement whether it is worth programming > it, or whether it bears such flaws that it makes not much sense to invest > any more time. Whether or not that decision is done by an Oracle employee > or not, he simply needs to know whom to sent his proposal for early review. > > -Markus > > -Original Message- > From: openjfx-dev [mailto:openjfx-dev-boun...@openjdk.java.net] On Behalf > Of Philip Race > Sent: Mittwoch, 6. Dezember 2017 06:50 > To: John-Val Rose > Cc: openjfx-dev@openjdk.java.net > Subject: Re: Innovation again (was Re: Text classes) > > There needs to be a viable community that is not just Oracle to support > you here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > > On 12/5/17, 9:27 PM, John-Val Rose wrote: > > Well, that’s all fine but you didn’t address the issue of working with > someone within Oracle to get these innovations done. > > > > Sure, I could just toil away by myself but clearly it would be better > all around if there was someone with much more extensive knowledge of > JavaFX and its internals who was accessible when required. > > > > I would assume that a member of the Oracle JavaFX team would be such a > person. If not, then who? > > > >> On 6 Dec 2017, at 15:53, Philip Race wrote: > >> > >> I think looking at it as an Oracle-owned and controlled project maybe > the first mistake here. > >> Yes it was closed source and then Oracle controlled, but not any more, > OCA requirements aside. > >> It is not even a "java specification". It can be evolved at an API > level without a JSR. > >> The JEP process is the main thing to be followed, although we also use > CSRs too to track API. > >> Consider it that anyone who is a contributor owns (not the right word > ?) a piece of it too. > >> So standing on the project is what matters. Not the company who pays > you to work on it. > >> > >> -phil. > >> > >>> On 12/5/17, 8:21 PM, John-Val Rose wrote: > >>> Phil et. al., > >>> > >>> Whilst I’m not going to be quite as “passionate” as some on this issue > (although I do understand the frustration), I would like to point out again > that this is indeed a huge gap and it is critical that it is filled ASAP. > >>> > >>> Obviously a solution where every word in a text document is a Node > would be unworkable so it would need to be architected from the ground up. > >>> > >>> I would be happy to work on such as feature, just as I was happy to > work on implementing WebGL, but my hesitation is concern over the > assistance and involvement from Oracle. > >>> > >>> If I am going to have to spend months working on something without any > or only minimal involvement from Oracle, only to find at the end that > Oracle either doesn’t like the design, implementation or something else > then it is wasted time I’ll never get back. > >>> > >>> There are lots of other innovati
Re: Innovation again (was Re: Text classes)
Absolutely - there needs to be a viable community that is not just Oracle. So, is there one? If not, how do we build one? OK, so let me rephrase my earlier email: I am willing to work with *anyone* (within Oracle or not) on the features that the community craves, such as those I listed (and any others). Not just because “many hands make light work” but because I don’t know everything (or even close) and I need the knowledge and skills of others to assist me. Not to mention that I have only 24 hours in a day like everyone else and, also like everyone else, some of that time has to be devoted to earning an income. So, if there’s anyone reading this who has the time, the skills, the commitment and the passion to work hard (in your own time) to get these tasks done then please contact me privately. > On 6 Dec 2017, at 16:50, Philip Race wrote: > > There needs to be a viable community that is not just Oracle to support you > here .. > I think everyone has come to be dependent on Oracle to "be there". > But if there is a specific community need that Oracle doesn't see as > essential, then the community should help out. > > -phil. > >> On 12/5/17, 9:27 PM, John-Val Rose wrote: >> Well, that’s all fine but you didn’t address the issue of working with >> someone within Oracle to get these innovations done. >> >> Sure, I could just toil away by myself but clearly it would be better all >> around if there was someone with much more extensive knowledge of JavaFX and >> its internals who was accessible when required. >> >> I would assume that a member of the Oracle JavaFX team would be such a >> person. If not, then who? >> >>> On 6 Dec 2017, at 15:53, Philip Race wrote: >>> >>> I think looking at it as an Oracle-owned and controlled project maybe the >>> first mistake here. >>> Yes it was closed source and then Oracle controlled, but not any more, OCA >>> requirements aside. >>> It is not even a "java specification". It can be evolved at an API level >>> without a JSR. >>> The JEP process is the main thing to be followed, although we also use CSRs >>> too to track API. >>> Consider it that anyone who is a contributor owns (not the right word ?) a >>> piece of it too. >>> So standing on the project is what matters. Not the company who pays you to >>> work on it. >>> >>> -phil. >>> >>>> On 12/5/17, 8:21 PM, John-Val Rose wrote: >>>> Phil et. al., >>>> >>>> Whilst I’m not going to be quite as “passionate” as some on this issue >>>> (although I do understand the frustration), I would like to point out >>>> again that this is indeed a huge gap and it is critical that it is filled >>>> ASAP. >>>> >>>> Obviously a solution where every word in a text document is a Node would >>>> be unworkable so it would need to be architected from the ground up. >>>> >>>> I would be happy to work on such as feature, just as I was happy to work >>>> on implementing WebGL, but my hesitation is concern over the assistance >>>> and involvement from Oracle. >>>> >>>> If I am going to have to spend months working on something without any or >>>> only minimal involvement from Oracle, only to find at the end that Oracle >>>> either doesn’t like the design, implementation or something else then it >>>> is wasted time I’ll never get back. >>>> >>>> There are lots of other innovations too that I would like to see in JavaFX >>>> but I just don’t “feel the enthusiasm” from Oracle. >>>> >>>> If there is someone on the JavaFX team who would be willing to work with >>>> me (at least in some capacity), please have them contact me privately via >>>> email. >>>> >>>> The innovations I could work on and contribute include: >>>> >>>> 1. WebGL support in WebView >>>> 2. Better text support including text documents& rich text editors etc. >>>> 3. Significant improvements in scene graph rendering speed using modern >>>> game-engine style structures and algorithms >>>> >>>> JavaFX cannot survive without innovation and I am keen to see it happen >>>> and contribute as much as possible. >>>> >>>> Graciously, >>>> >>>> John-Val Rose >>>> Rosethorn Technology >>>> >>>>> On 6 Dec 2017, at 11:36, jav...@use.startmail.com w
Re: Innovation again (was Re: Text classes)
Well, that’s all fine but you didn’t address the issue of working with someone within Oracle to get these innovations done. Sure, I could just toil away by myself but clearly it would be better all around if there was someone with much more extensive knowledge of JavaFX and its internals who was accessible when required. I would assume that a member of the Oracle JavaFX team would be such a person. If not, then who? > On 6 Dec 2017, at 15:53, Philip Race wrote: > > I think looking at it as an Oracle-owned and controlled project maybe the > first mistake here. > Yes it was closed source and then Oracle controlled, but not any more, OCA > requirements aside. > It is not even a "java specification". It can be evolved at an API level > without a JSR. > The JEP process is the main thing to be followed, although we also use CSRs > too to track API. > Consider it that anyone who is a contributor owns (not the right word ?) a > piece of it too. > So standing on the project is what matters. Not the company who pays you to > work on it. > > -phil. > >> On 12/5/17, 8:21 PM, John-Val Rose wrote: >> Phil et. al., >> >> Whilst I’m not going to be quite as “passionate” as some on this issue >> (although I do understand the frustration), I would like to point out again >> that this is indeed a huge gap and it is critical that it is filled ASAP. >> >> Obviously a solution where every word in a text document is a Node would be >> unworkable so it would need to be architected from the ground up. >> >> I would be happy to work on such as feature, just as I was happy to work on >> implementing WebGL, but my hesitation is concern over the assistance and >> involvement from Oracle. >> >> If I am going to have to spend months working on something without any or >> only minimal involvement from Oracle, only to find at the end that Oracle >> either doesn’t like the design, implementation or something else then it is >> wasted time I’ll never get back. >> >> There are lots of other innovations too that I would like to see in JavaFX >> but I just don’t “feel the enthusiasm” from Oracle. >> >> If there is someone on the JavaFX team who would be willing to work with me >> (at least in some capacity), please have them contact me privately via email. >> >> The innovations I could work on and contribute include: >> >> 1. WebGL support in WebView >> 2. Better text support including text documents& rich text editors etc. >> 3. Significant improvements in scene graph rendering speed using modern >> game-engine style structures and algorithms >> >> JavaFX cannot survive without innovation and I am keen to see it happen and >> contribute as much as possible. >> >> Graciously, >> >> John-Val Rose >> Rosethorn Technology >> >>> On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote: >>> >>> Sorry about all the typos previously. >>> >>> Question- why not use the code in awt ? I am not totally up on what's going >>> on with the platforms' native rendering engines ( meaning, I have no idea >>> whatsoever) or how they have changed, but golly it sure does still work >>> pretty well. >>> >>> At least it seems to me looking at awt that a smallish number of things >>> are 1) well defined by the native platofrm and 2) would more or less >>> translate directly to an Java API and 3) from those small number of >>> building blocks, (Font and Glyph metrics and this kind of thing) text >>> line layout algorithms can be written by ordinary civilians along with all >>> the other stuff that goes into a text editor. >>> >>> And yes, everything does look easy when someone else is going to do it. >>> >>>
Innovation again (was Re: Text classes)
Phil et. al., Whilst I’m not going to be quite as “passionate” as some on this issue (although I do understand the frustration), I would like to point out again that this is indeed a huge gap and it is critical that it is filled ASAP. Obviously a solution where every word in a text document is a Node would be unworkable so it would need to be architected from the ground up. I would be happy to work on such as feature, just as I was happy to work on implementing WebGL, but my hesitation is concern over the assistance and involvement from Oracle. If I am going to have to spend months working on something without any or only minimal involvement from Oracle, only to find at the end that Oracle either doesn’t like the design, implementation or something else then it is wasted time I’ll never get back. There are lots of other innovations too that I would like to see in JavaFX but I just don’t “feel the enthusiasm” from Oracle. If there is someone on the JavaFX team who would be willing to work with me (at least in some capacity), please have them contact me privately via email. The innovations I could work on and contribute include: 1. WebGL support in WebView 2. Better text support including text documents & rich text editors etc. 3. Significant improvements in scene graph rendering speed using modern game-engine style structures and algorithms JavaFX cannot survive without innovation and I am keen to see it happen and contribute as much as possible. Graciously, John-Val Rose Rosethorn Technology > On 6 Dec 2017, at 11:36, jav...@use.startmail.com wrote: > > Sorry about all the typos previously. > > Question- why not use the code in awt ? I am not totally up on what's going > on with the platforms' native rendering engines ( meaning, I have no idea > whatsoever) or how they have changed, but golly it sure does still work > pretty well. > > At least it seems to me looking at awt that a smallish number of things are > 1) well defined by the native platofrm and 2) would more or less translate > directly to an Java API and 3) from those small number of building blocks, > (Font and Glyph metrics and this kind of thing) text line layout algorithms > can be written by ordinary civilians along with all the other stuff that goes > into a text editor. > > And yes, everything does look easy when someone else is going to do it. > >
Re: Text classes
+1 A full-featured API to enable rich text and syntax highlighting in editors is *very* much needed. All the attempts I have seen at creating such editors with JavaFX are basically “fudges”. I have never seen HTMLEditor used in a real-world application. > On 26 Nov 2017, at 10:40, jav...@use.startmail.com wrote: > > Hi, This is a question about the future of Text under Javafx. > > Very briefly, Swing provided access to everything a dev could need in order > to write a rich text editor from scratch. LineBreakMeasurers and HitTesting > and everything. > > In JavaFX these things are not directly available to the dev and anyway, to > the extent that they are, they cannot be used to write a rich text editor.. > > There are many classes needed involving the measuring of glyphs and text > lines etc etc etc which would be needed for anyone who wanted to write their > own rich text editor. They exist, but are under sun.com and given the > modularization of Java 9 are truly inaccessible to developers. > > I am aware of the existing Javafx controls. I am also aware of the efforts > available at GitHub and elsewhere to create a rich text editor and all of > them without exception are handicapped by this same lack of API. > > I am also aware of HTMLEditor in JavaFX but that 1) commits the dev to > WebRenderer and 2) still doesn't provide access to the needed classes and > methods. It's not sufficient to suppose that HTML 5 or whatever follows is > the answer to all text layout challenges. > > Formerly, Swing had all these missing features available as API and many good > text editors were created using those APIs. > > For the sake of future planning, we really need to know- is there any > recognition within Oracle that this is something which has to be addressed? > Is it on any hypothetical roadmap? Or is HTMLEditor as much as JavaFX is > going to provide ? > > Thank you.
Re: JavaOne slides about Marlin/FX renderer
Hi Laurent, You have my full support. I have emailed your privately and believe we can work together to improve JavaFX in the ways you mentioned. BTW: MarlinFX is a truly awesome contribution. Thanks on behalf of the JavaFX community! Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 13 October 2017 at 20:20, Laurent Bourgès wrote: > Hi, > > Here are my final JavaOne slides about the Marlin & MarlinFX renderers: > https://github.com/bourgesl/bourgesl.github.io/raw/master/ja > vaone2017/slides/javaone-marlin-talk.pdf > > You will also get links to my github repositories... > > Please join me in my efforts improving either Java2D or JavaFX > (performance, quality, better 3D support in JFX) by contributing to the > Marlin project or sponsoring me working for the java community (OpenJDK & > OpenJFX). > > Cheers, > Laurent >
Re: OpenJFX initiative
Hi Mark, I didn't actually "describe a proposed roadmap"; I merely questioned why there doesn't appear to be one. What does that mean? Well, it could mean that one exists but that Oracle prefers to not make it public. It could mean that their still developing one. Or it could mean that the roadmap is an "all roads lead to Rome" scenario where "Rome" is a euphemism for obsolescence. If you look back the other way, i.e. the path travelled so far, you see that there was one major change in the architecture of JavaFX between versions 1 and 2. Then they went straight to 8 (when they decided to align the version numbers with JDK versions) but the changes were not really that significant. Sure, they introduced *some* 3D features which are now basically frozen and a couple of new controls etc. but mostly JavaFX 8 was better than 2 because we got to use all the nifty new Java 8 language features like lambdas and streams. Then, if you look at JavaFX 9, it seems to be little more than a "jigsawed" version of Java 8. Now, look more closely at the time elapsed from JavaFX 2 to 9 and you discover that between 2011 and 2017, there has been extremely limited innovation and no significant changes or major new features. Quite frankly, I have never seen a product of this kind evolve so slowly. Further, given that JavaFX entered the market and commenced it's slow evolutionary path years (if not decades) behind established competitors, this is the real *main* issue with JavaFX: it can't compete with something like Qt on *any* basis including features, cross-platform support, performance, professional support or user base, and that "gap" widens every day. (Forget about the web and HTML5. They/it are not a competitor to JavaFX). So, as for you idea about "promotion" of JavaFX, you must factor in that if you are trying to sell a product on the basis of any of the factors I just mentioned, then Qt (and others like Xamarin) will trump JavaFX on every one of them. Further, both Qt and Xamarin (now owned and heavily financed by Microsoft) have large companies behind them that actually generate revenue from them (which is a GOOD thing because it ensures their survival and enables rapid innovation). Also, it is yet to be seen if JavaFX is even viable on mobile/tablet platforms. We will only know when Gluon release their Gluon VM. So, it's probably not wise to go around now promoting what is (at least right now) still basically "vapourware". (N.B. I *do* have full confidence in Johan Vos and Gluon to deliver on their promise of a "blisteringly fast Java experience on iOS and Android" - I just need to get my hands on it, as do all JavaFX developers). As for me, well, all I want to do is contribute whatever I can to improve JavaFX. My comments are not meant as an "attack" on JavaFX (which is actually something I love), but more a shot of reality and a "battle cry". It's not too late for JavaFX but a lot of things need to change and change soon for it be viable long term. We have a vibrant community and I believe we need a mechanism to coordinate all the passion and talent into an army of JavaFX soldiers, all with the unified vision to "make JavaFX great again" (only without the fake news, alternate facts, rhetoric, gaffes and, of course... no comb-overs). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 24 September 2017 at 00:14, Mark Fortner wrote: > I must have missed the bit where you described a proposed roadmap. > > I think for the most part I've seen JavaFX used as a means of keeping > older Swing-based projects alive. In the enterprise, those projects are > dwindling, in part because people just rebuild them as web applications. > It's easier to find that kind of talent, than it is to find desktop > developers. > > The applications that remain desktop applications tend to require either > access to your desktop OS, or need near realtime access to streams of > audio, video, telemetry or financial data, which makes them ill-suited to > be web apps. > > The reason that there's little interest in WebGL or 3d is because it > doesn't fit into one of the enterprise app buckets listed above. > > I'm still surprised when people tell me that they have to write mobile > apps in Java and Swift and maintain two codebases, and when I point them to > JavaFX they admit they've never heard of it. > > There needs to be better promotion of JavaFX in the Java developer > community. People need to compare the degree of complexity of web component > and PWA development against JavaFX to see the advantages. And there needs > to be a better deployment story than web start. > > A lot of that is simply promotion. It means reaching out to web > dev
Re: OpenJFX initiative
Probably, but JEPs can take a lot of time from start to finish and time is itself perhaps the biggest enemy that JavaFX is facing. And how many JEPs are being initiated by the Oracle JavaFX team themselves? I mean for the specific purpose of *true* innovation? On 23 September 2017 at 10:24, Nir Lisker wrote: > I don't have any answer to those questions. A JEP is the only thing I can > think of. > > On Sat, Sep 23, 2017 at 3:19 AM, John-Val Rose > wrote: > >> Yes, well I'm sure there's a lot of truth to that as Johan has >> demonstrated. >> >> But, I think it's a bit of an over simplification. >> >> How do I know if *my* innovation (of say 9 months of effort) is "high-quality >> code that makes OpenJFX better"? >> >> I can do my best to write high-quality code but what exactly does "make >> OpenJFX better" mean? *I* might think it's better with WebGL and advanced >> 3D features but it seems most people disagree or are ambivalent towards >> such functionality. >> >> Who gets to say what does or doesn't get integrated? And, how do I know >> *before* I potentially waste my effort whether it will or won't "make >> OpenJFX better" or be integrated? >> >> >> Graciously, >> >> John-Val Rose >> Chief Scientist/Architect >> Rosethorn Technology >> Australia >> >> On 23 September 2017 at 09:08, Nir Lisker wrote: >> >>> > What do you mean by “go with Johan Vos’s experience”? >>> >>> What he said here: http://mail.openjdk.java >>> .net/pipermail/openjfx-dev/2017-September/020801.html. >>> >>> On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose >>> wrote: >>> >>>> The concept of “innovation” no longer seems to apply to JavaFX, at >>>> least not from Oracle’s perspective. >>>> >>>> If you read the official list of changes in the just-released Java 9, >>>> AWT (yes, AWT) has more changes than JavaFX and even then the only >>>> significant change is to make it Jigsaw compatible. >>>> >>>> A product like this needs a very clear “roadmap” of development and >>>> introduction of new features but the link on the Oracle JavaFX >>>> Documentation page for “roadmap” leads to a place known as “404”. I hope >>>> that’s not a room number in “Hotel California”. >>>> >>>> So, innovation for JavaFX falls back as a community responsibility but >>>> is very difficult without any cooperation from Oracle themselves. >>>> >>>> I personally have not been able to get any response from them except >>>> “float your ideas on the mailing list to see what interest there is”. Note, >>>> that “interest” is only from the community itself... and then what? >>>> >>>> What do you mean by “go with Johan Vos’s experience”? Yes, he and Gluon >>>> are fantastic innovators and have built a small company of top-notch talent >>>> and are able to crank-out new products and enhancements with impressive >>>> frequency. >>>> >>>> Are you suggesting we all start similar companies? Johan is a former >>>> Oracle employee and probably has a well-established relationship with them >>>> and access to knowledge that others don’t. Personally, I love what he’s >>>> doing and hope Gluon expands rapidly to enable as much innovation as >>>> possible. >>>> >>>> But what about the rest of us? What are we supposed to do? How do we >>>> get large-scale changes to happen? >>>> >>>> Well, I don’t know. But we’re better as a team than a bunch of >>>> individuals each trying to get some feature implemented in an uncoordinated >>>> fashion. >>>> >>>> The other real issue is that everyone seems to have their own >>>> perspective on exactly what JavaFX is or should be. That makes the >>>> community ineffective unless someone manages innovation for JavaFX in >>>> general. >>>> >>>> I’d be happy to be that person but sadly, it’s not for me to make that >>>> call. Johan is like the de facto “Head of Innovation for JavaFX” at the >>>> moment but he has his own agenda (mainly in the mobile space) and monetises >>>> his efforts. >>>> >>>> That’s what businesses do. >>>> >>>> So, I think we need to firstly establish just what JavaFX is *now* >>>> (even this is not clear) and also what it *should be* (where we coalesce >>>> everyone’s own ideas) so we can move forward. >>>> >>>> That is of course *if* JavaFX is actually going to “move forward” >>>> rather than “sideways”. >>>> >>>> Honestly though, if you’re not moving forward, you are really going >>>> backward as you watch the rest of the world disappear over the horizon... >>>> >>>> Graciously, >>>> >>>> John-Val Rose >>>> >>>> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >>>> > >>>> > I didn't see any update on the idea for our initiative. Are we still >>>> waiting for a reply from Oracle or do we go with Johan Vos's experience? >>>> > >>>> > I think that the least we can do without putting any work into this >>>> is have a semi-formal list of people who would like to work on this and a >>>> list of what features we would be working on. I feel that I still don't >>>> know the scope of what we are trying to do, only pieces of it. >>>> >>> >>> >> >
Re: OpenJFX initiative
Yes, well I'm sure there's a lot of truth to that as Johan has demonstrated. But, I think it's a bit of an over simplification. How do I know if *my* innovation (of say 9 months of effort) is "high-quality code that makes OpenJFX better"? I can do my best to write high-quality code but what exactly does "make OpenJFX better" mean? *I* might think it's better with WebGL and advanced 3D features but it seems most people disagree or are ambivalent towards such functionality. Who gets to say what does or doesn't get integrated? And, how do I know *before* I potentially waste my effort whether it will or won't "make OpenJFX better" or be integrated? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology Australia On 23 September 2017 at 09:08, Nir Lisker wrote: > > What do you mean by “go with Johan Vos’s experience”? > > What he said here: http://mail.openjdk.java.net/pipermail/openjfx- > dev/2017-September/020801.html. > > On Sat, Sep 23, 2017 at 12:08 AM, John-Val Rose > wrote: > >> The concept of “innovation” no longer seems to apply to JavaFX, at least >> not from Oracle’s perspective. >> >> If you read the official list of changes in the just-released Java 9, AWT >> (yes, AWT) has more changes than JavaFX and even then the only significant >> change is to make it Jigsaw compatible. >> >> A product like this needs a very clear “roadmap” of development and >> introduction of new features but the link on the Oracle JavaFX >> Documentation page for “roadmap” leads to a place known as “404”. I hope >> that’s not a room number in “Hotel California”. >> >> So, innovation for JavaFX falls back as a community responsibility but is >> very difficult without any cooperation from Oracle themselves. >> >> I personally have not been able to get any response from them except >> “float your ideas on the mailing list to see what interest there is”. Note, >> that “interest” is only from the community itself... and then what? >> >> What do you mean by “go with Johan Vos’s experience”? Yes, he and Gluon >> are fantastic innovators and have built a small company of top-notch talent >> and are able to crank-out new products and enhancements with impressive >> frequency. >> >> Are you suggesting we all start similar companies? Johan is a former >> Oracle employee and probably has a well-established relationship with them >> and access to knowledge that others don’t. Personally, I love what he’s >> doing and hope Gluon expands rapidly to enable as much innovation as >> possible. >> >> But what about the rest of us? What are we supposed to do? How do we get >> large-scale changes to happen? >> >> Well, I don’t know. But we’re better as a team than a bunch of >> individuals each trying to get some feature implemented in an uncoordinated >> fashion. >> >> The other real issue is that everyone seems to have their own perspective >> on exactly what JavaFX is or should be. That makes the community >> ineffective unless someone manages innovation for JavaFX in general. >> >> I’d be happy to be that person but sadly, it’s not for me to make that >> call. Johan is like the de facto “Head of Innovation for JavaFX” at the >> moment but he has his own agenda (mainly in the mobile space) and monetises >> his efforts. >> >> That’s what businesses do. >> >> So, I think we need to firstly establish just what JavaFX is *now* (even >> this is not clear) and also what it *should be* (where we coalesce >> everyone’s own ideas) so we can move forward. >> >> That is of course *if* JavaFX is actually going to “move forward” rather >> than “sideways”. >> >> Honestly though, if you’re not moving forward, you are really going >> backward as you watch the rest of the world disappear over the horizon... >> >> Graciously, >> >> John-Val Rose >> >> > On 22 Sep 2017, at 22:38, Nir Lisker wrote: >> > >> > I didn't see any update on the idea for our initiative. Are we still >> waiting for a reply from Oracle or do we go with Johan Vos's experience? >> > >> > I think that the least we can do without putting any work into this is >> have a semi-formal list of people who would like to work on this and a >> list of what features we would be working on. I feel that I still don't >> know the scope of what we are trying to do, only pieces of it. >> > >
Re: OpenJFX initiative
The concept of “innovation” no longer seems to apply to JavaFX, at least not from Oracle’s perspective. If you read the official list of changes in the just-released Java 9, AWT (yes, AWT) has more changes than JavaFX and even then the only significant change is to make it Jigsaw compatible. A product like this needs a very clear “roadmap” of development and introduction of new features but the link on the Oracle JavaFX Documentation page for “roadmap” leads to a place known as “404”. I hope that’s not a room number in “Hotel California”. So, innovation for JavaFX falls back as a community responsibility but is very difficult without any cooperation from Oracle themselves. I personally have not been able to get any response from them except “float your ideas on the mailing list to see what interest there is”. Note, that “interest” is only from the community itself... and then what? What do you mean by “go with Johan Vos’s experience”? Yes, he and Gluon are fantastic innovators and have built a small company of top-notch talent and are able to crank-out new products and enhancements with impressive frequency. Are you suggesting we all start similar companies? Johan is a former Oracle employee and probably has a well-established relationship with them and access to knowledge that others don’t. Personally, I love what he’s doing and hope Gluon expands rapidly to enable as much innovation as possible. But what about the rest of us? What are we supposed to do? How do we get large-scale changes to happen? Well, I don’t know. But we’re better as a team than a bunch of individuals each trying to get some feature implemented in an uncoordinated fashion. The other real issue is that everyone seems to have their own perspective on exactly what JavaFX is or should be. That makes the community ineffective unless someone manages innovation for JavaFX in general. I’d be happy to be that person but sadly, it’s not for me to make that call. Johan is like the de facto “Head of Innovation for JavaFX” at the moment but he has his own agenda (mainly in the mobile space) and monetises his efforts. That’s what businesses do. So, I think we need to firstly establish just what JavaFX is *now* (even this is not clear) and also what it *should be* (where we coalesce everyone’s own ideas) so we can move forward. That is of course *if* JavaFX is actually going to “move forward” rather than “sideways”. Honestly though, if you’re not moving forward, you are really going backward as you watch the rest of the world disappear over the horizon... Graciously, John-Val Rose > On 22 Sep 2017, at 22:38, Nir Lisker wrote: > > I didn't see any update on the idea for our initiative. Are we still waiting > for a reply from Oracle or do we go with Johan Vos's experience? > > I think that the least we can do without putting any work into this is have a > semi-formal list of people who would like to work on this and a list of what > features we would be working on. I feel that I still don't know the scope of > what we are trying to do, only pieces of it.
Re: WebView and WebGL
Hi Jan, I have to say that I find your question rather "curious"! Imagine asking a Qt developer "Why do you need 3D in Qt?". They'd probably look at you a bit strangely and then reply "Is this a trick question?". If there weren't the (advanced) 3D features in Qt then most C++ developers would simply ignore it! We've moved a long, long way on from "simple forms based applications" into an exciting new world of visualisations, animations, games, big data, 3D charting etc. Or, have we? Well, most developers and businesses have... unless you're a Java shop. There, you're most likely to still be using Swing because it has an enormous range of controls (all of which are much easier to customise than JavaFX controls) and you have a range of high-quality GUI builders and a wealth of trained, skilled and experienced staff resources to find if you need them. And guess what? Two of the most advanced and utilised IDEs (JetBrains IntelliJ and Google Android SDK) are *Swing* applications! But, you're still basically just "doing forms" and while that may be adequate for many types of companies, it is also significantly impeding their technology progress and limiting their developer's potential. No, they don't want to throw away all their Java domain models and business logic, retrain everyone in C++ and then spend years rewriting a massive codebase only to find years later that they have spent millions on building a bug-infested shiny new toy that does little or nothing more than what they started with. And they don't want to buy into the "HTML5 hype" either. They're going to face a complete brick wall trying to do what I just described by shifting to browser-based technologies. My suggestion of implementing WebGL in WebView was merely a quick way to at least permit decent 3D functionality to finally "creep" into JavaFX and then hopefully kickstart a full-blown injection of advanced 3D features. Besides, if you're going to embed a browser in your JavaFX app (which is actually a very common and valid requirement), wouldn't you want it to be at least able to use Google Maps properly? JavaFX is at a crossroads. Please, let's take the right road... Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 12 Sep 2017, at 04:51, Jan Tosovsky wrote: > >> On 2017-09-10 Nir Lisker wrote: >> >> 3D enhancement are indeed not planned for Java10 (at the minimum) ... >> but I agree with Mike - you can, maybe somewhat surprisingly, do quite >> a lot with what there is. >> >> ... >> >> We've employed some clever tricks to get adequate "advanced features" >> results and considering that all of it can be single-handedly run on >> iOS and Android with Gluon Mobile (specifically JavaFXPorts) I think >> there *is* a future in this direction ... > > > Just for my curiosity, what is the main driver for developers to integrate 3D > into JavaFX apps? > > Why not create apps utilizing WebGL directly in (full-featured) browsers > using JavaScript bundled as GUI apps (via e.g. Meteor or CEF)? > > Is it about reusing Java knowledge, unique Java libraries, something else? > > Thanks for clarifying, > > Jan > > > > >
Re: Innovation (Was: WebView and WebGL)
Well, you would certainly know - thanks. That's very encouraging :-) > On 11 Sep 2017, at 20:02, Johan Vos wrote: > > From experience, I can tell you that if you do the work and write > high-quality code that makes OpenJFX better, I'm sure it will be possible to > integrate it. > > - Johan > > >> On Mon, Sep 11, 2017 at 3:00 AM John-Val Rose wrote: >> Thanks Nir. >> >> I am very aware of the formal processes involved but also cognisant of the >> considerable time/delays and "red tape" that can be an undesirable >> consequence of such formality. >> >> I'm also not a "hope for the best" kinda guy. >> >> I think first we really need (and really hope) someone from Oracle to make >> an official comment on all these matters to ensure, as you suggest, that any >> or all of our efforts are "successful". >> >> There are multiple ways for a "lack of success" to result that have nothing >> to do with the quality, correctness, efficiency or even the "value" of our >> contributions. >> >> There's absolutely no point in devoting one nanosecond of anyone's time to a >> project doomed to fail for reasons beyond our control. >> >> Oracle: can you please comment on these issues and the various ways to >> expedite implementation of both resolutions and (especially) increase the >> velocity of innovation? >> >> Graciously, >> >> John-Val Rose >> >> > On 11 Sep 2017, at 10:25, Nir Lisker wrote: >> > >> > I don't mind giving it a go but I wouldn't like doing the work and then it >> > not getting implemented (if the result is a success). >> > >> > Personally, I think that the first thing we should do is make a list of >> > what exactly it is we are trying to do if only to get a sense of the >> > magnitude and be sure we have enough of the right people to finish it. Then >> > we would, in all probability, need to write a JEP ( >> > http://openjdk.java.net/jeps/1) which also means we will need a project >> > lead. Then follow the JEP road and hope for the best I guess. >> > >> > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose >> > wrote: >> > >> >> Nir, >> >> >> >> You're not "hijacking" anything - I think it's been established that this >> >> a broader "3D API support" issue. In fact, even broader than that. >> >> >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> >> tried to analyse the present and anticipate the future. >> >> >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> >> as it is and makes the most of it, sometimes in stunning and amazing ways >> >> but they don't seem to like to rock the boat or try to force the >> >> improvement of JavaFX itself so much. >> >> >> >> Then there's the others who get frustrated, ask for change, offer to >> >> enable change or put on their boots and make change. A lot of them seem to >> >> get "burned". >> >> >> >> We need people from both camps: one to showcase what can be done with what >> >> we have in surprising ways and the others to drive innovation. >> >> >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> >> if you are passionate about something, you just go with it. >> >> >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> >> when discussing innovation and the future feature plans. As in this >> >> thread, >> >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has >> > I don't mind giving it a go but I wouldn't like doing the work and then it >> > not getting implemented (if the result is a success). >> > >> > Personally, I think that the first thing we should do is make a list of >> > what exactly it is we are trying to do if only to get a sense of the >> > magnitude and be sure we have enough of the right people to finish it. Then >> > we would, in all probability, need to write a JEP ( >> > http://openjdk.java.net/jeps/1) which also means we will need a project >> > lead. Then follow
Re: Innovation (Was: WebView and WebGL)
Thanks Nir. I am very aware of the formal processes involved but also cognisant of the considerable time/delays and "red tape" that can be an undesirable consequence of such formality. I'm also not a "hope for the best" kinda guy. I think first we really need (and really hope) someone from Oracle to make an official comment on all these matters to ensure, as you suggest, that any or all of our efforts are "successful". There are multiple ways for a "lack of success" to result that have nothing to do with the quality, correctness, efficiency or even the "value" of our contributions. There's absolutely no point in devoting one nanosecond of anyone's time to a project doomed to fail for reasons beyond our control. Oracle: can you please comment on these issues and the various ways to expedite implementation of both resolutions and (especially) increase the velocity of innovation? Graciously, John-Val Rose > On 11 Sep 2017, at 10:25, Nir Lisker wrote: > > I don't mind giving it a go but I wouldn't like doing the work and then it > not getting implemented (if the result is a success). > > Personally, I think that the first thing we should do is make a list of > what exactly it is we are trying to do if only to get a sense of the > magnitude and be sure we have enough of the right people to finish it. Then > we would, in all probability, need to write a JEP ( > http://openjdk.java.net/jeps/1) which also means we will need a project > lead. Then follow the JEP road and hope for the best I guess. > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > wrote: > >> Nir, >> >> You're not "hijacking" anything - I think it's been established that this >> a broader "3D API support" issue. In fact, even broader than that. >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> tried to analyse the present and anticipate the future. >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> as it is and makes the most of it, sometimes in stunning and amazing ways >> but they don't seem to like to rock the boat or try to force the >> improvement of JavaFX itself so much. >> >> Then there's the others who get frustrated, ask for change, offer to >> enable change or put on their boots and make change. A lot of them seem to >> get "burned". >> >> We need people from both camps: one to showcase what can be done with what >> we have in surprising ways and the others to drive innovation. >> >> I'm clearly in the 2nd group and I'm finding that there are quite a few of >> us. I'm not so afraid of "getting burned" as we all take risks in life and >> if you are passionate about something, you just go with it. >> >> But, the most disappointing aspect is that Oracle staff are often "M.I.A." >> when discussing innovation and the future feature plans. As in this thread, >> Oracle haven't exactly been chiming-in (and yes, I know a lot of it has > I don't mind giving it a go but I wouldn't like doing the work and then it > not getting implemented (if the result is a success). > > Personally, I think that the first thing we should do is make a list of > what exactly it is we are trying to do if only to get a sense of the > magnitude and be sure we have enough of the right people to finish it. Then > we would, in all probability, need to write a JEP ( > http://openjdk.java.net/jeps/1) which also means we will need a project > lead. Then follow the JEP road and hope for the best I guess. > > On Sun, Sep 10, 2017 at 11:29 PM, John-Val Rose > wrote: > >> Nir, >> >> You're not "hijacking" anything - I think it's been established that this >> a broader "3D API support" issue. In fact, even broader than that. >> >> I'm only new on the JavaFX "scene" but I've looked through the history and >> tried to analyse the present and anticipate the future. >> >> It seems that there are 2 main groups of JavaFX users: one that takes it >> as it is and makes the most of it, sometimes in stunning and amazing ways >> but they don't seem to like to rock the boat or try to force the >> improvement of JavaFX itself so much. >> >> Then there's the others who get frustrated, ask for change, offer to >> enable change or put on their boots and make change. A lot of them seem to >> get "burned". >> >> We need people from both camps: one to showcase what can be done with
Innovation (Was: WebView and WebGL)
Nir, You're not "hijacking" anything - I think it's been established that this a broader "3D API support" issue. In fact, even broader than that. I'm only new on the JavaFX "scene" but I've looked through the history and tried to analyse the present and anticipate the future. It seems that there are 2 main groups of JavaFX users: one that takes it as it is and makes the most of it, sometimes in stunning and amazing ways but they don't seem to like to rock the boat or try to force the improvement of JavaFX itself so much. Then there's the others who get frustrated, ask for change, offer to enable change or put on their boots and make change. A lot of them seem to get "burned". We need people from both camps: one to showcase what can be done with what we have in surprising ways and the others to drive innovation. I'm clearly in the 2nd group and I'm finding that there are quite a few of us. I'm not so afraid of "getting burned" as we all take risks in life and if you are passionate about something, you just go with it. But, the most disappointing aspect is that Oracle staff are often "M.I.A." when discussing innovation and the future feature plans. As in this thread, Oracle haven't exactly been chiming-in (and yes, I know a lot of it has occurred outside of normal working hours). So Nir, Laurent (and the many others who are putting their hands up), perhaps we should collaborate and not just "casually". OpenJFX is, after all, "open" so perhaps a more formally coordinated team of motivated community members can pool our resources and skills and "Just do it" (with or without Oracle's help). I like what you are suggesting and what Sverre is requesting and what numerous others are wanting, and I for one *want* them to become realities. Quite frankly, I don't see these changes and innovations (especially) actually being realised any other way. Comments? Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 10 Sep 2017, at 23:13, Nir Lisker wrote: > > I don't want to hijack the WebGL discussion but since it rolled into the 3D > library territory anyway I'll give my 2 cents. > > 3D enhancement are indeed not planned for Java10 (at the minimum) and > indeed you can't bring your own shader (asked already at > https://stackoverflow.com/questions/43622856/can-we-implement-our-own-materials-in-javafx), > but I agree with Mike - you can, maybe somewhat surprisingly, do quite a > lot with what there is. > > Perhaps the most limiting feature is not supporting industry standards of > 3D modeling via converters (import/export). It has been suggested ( > https://bugs.openjdk.java.net/browse/JDK-8091851) but last activity was 5 > years ago. As for shaders (materials), lightings etc., from what I remember > by looking around in the source, it will take some effort to rewrite the > API to be able to accept custom ones but it's far from impossible. If Phong > is implemented there's little reason reason others won't fit (maybe > reflective surfaces don't work). Similarly a directional light can be based > on the implemented point light be using a cone instead of a sphere. > > We've employed some clever tricks to get adequate "advanced features" > results and considering that all of it can be single-handedly run on iOS > and Android with Gluon Mobile (specifically JavaFXPorts) I think there *is* > a future in this direction and I'm willing to team up with whomever is > interested provided we can get minimal support from the Oracle team.
Re: WebView and WebGL
...if only you could "bring your own" shader :-; On 10 Sep 2017, at 21:04, Mike Hearn wrote: >> >> (And yes, the current JavaFX 3D features are extremely rudimentary and not >> particularly useful. I don't expect them to be ever enhanced. They're >> effectively "frozen". It's a harsh call but I think they were a mistake >> from day one. We need a completely different alternative). >> > > I somewhat agree, but at the time - lacking something like ANGLE - there > was no alternative. And it's sufficient to be able to put a UI surface onto > a cube and spin it around, and other simple but effective animation > techniques. As macOS has showed you don't need a full blown 3D engine to > make good use of a GPU: just tasteful use of basic shapes, animations and > shader effects gets you a long way, and FX does support those.
Re: WebView and WebGL
Yes Scott, the rendering in WebView is done with the JavaFX API which has pros and cons. The major "pro" is that it is a lightweight control that plays nicely with all other controls (and the performance is surprisingly good). The "con" is that implementing WebGL was thus very complicated (with the issues about OpenGL on Windows already mentioned) and therefore omitted. As I mentioned in another post, the product "JxBrowser" which is based on Chromium is a heavyweight control where all the rendering is done by Chromium itself. This makes it perform just as well as Chrome and supports WebGL and full-mode Google Maps. It looks like a great choice until you want to use other (lightweight) controls with it. The native rendering will just override anything you do over the top of JxBrowser and that age-old problem of trying to mix heavyweight and lightweight controls is highlighted. But, if you just want a real HTML5 browser control in your JavaFX app surrounded by normal controls, it works great (if you can afford it!). But it isn't portable to iOS or Android either with tools like Gluon Mobile. It is NOT the correct, long-term solution to enabling proper, advanced OpenGL support in JavaFX, either in a 3D Canvas or in WebView. Determining the best solution & making it work is now my mission :-) (And yes, the current JavaFX 3D features are extremely rudimentary and not particularly useful. I don't expect them to be ever enhanced. They're effectively "frozen". It's a harsh call but I think they were a mistake from day one. We need a completely different alternative). Graciously, John-Val Rose Chief Scientist/Architect Rosethorn Technology > On 10 Sep 2017, at 08:16, Scott Palmer wrote: > > If I’m remembering correctly, I think the another factor for why WebGL wasn’t > included is that the rendering layer of WebKit was done on top of JavaFX. > That allows it to integrate nicely with the all the other JavaFX rendering. > > Personally I wish that time wasn’t wasted (IMO) on the existing 3D support > and instead proper OpenGL support was done for JavaFX - *outside* of WebKit. > I think that might have required solving another problem - integrating a > native rendering surface into the scene graph. That would have allowed me to > solve other problems, such as showing realtime video from a camera or other > image sources, that the existing media API doesn’t support. > > My issue requesting extensible media support is coming up on its 9-year > anniversary: > https://bugs.openjdk.java.net/browse/JDK-8091063 > (It’s closed now as it is marked as a duplicate of issues that were created > later, even though those issues don’t adequately cover what is required.) > > > Frankly I have very little use for WebKit in a JavaFX application (other than > for displaying help pages or something). If I’m going to make a web app, I > will just make a web app. JavaFX would only serve to make a web app less > accessible. I would of course never make a web app where a proper desktop > app is more appropriate, because they always suck compared to apps that > aren’t crippled by running in a browser. :-) > > > Scott > > >> On Sep 9, 2017, at 11:06 AM, Mike Hearn wrote: >> >> I'm not on the FX team, but I'd suggest just starting work on it and see how >> far you get. You might duplicate some of the research the FX engineers are >> doing but you also might not, or you might find yourself being able to >> influence the direction of the project with unique input. >> >> If you can make WebGL work in WebKit, I guess it's not much harder to expose >> an eGL binding via JavaFX itself as WebGL is basically eGL for the web. >> >> I'd like to see GL support in JavaFX, if only because I enjoy blinging apps >> I write, including business apps! The embedded video player is invaluable >> for this sort of thing too. >> >> 1. Why wasn't WebGL support implemented from day zero given that WebKit >> supports it? >> >> I am going to take a stab at these answers based on my relatively poor >> understanding of how JavaFX works. Answers worth what you paid for them. >> >> I'm going to guess that the answer is Windows. > >
Re: WebView and WebGL
Thanks guys - that sounds like a good "angle" to approach this :-; I too suspected that Windows and poor OpenGL support was at the heart of the matter after the decades-long "API Wars". I just didn't realise that OpenGL on Windows was that inferior/buggy to Direct3D (by design, of course!). I will start investigating and I definitely agree that it's not really just about WebView, although that's a good first candidate. I guess I'm just a bit disappointed that it has only been community members who have replied on this important issue. Surely my mission will be easier if Oracle guide and assist me... Graciously, John-Val Rose > On 10 Sep 2017, at 01:06, Mike Hearn wrote: > > I'm not on the FX team, but I'd suggest just starting work on it and see > how far you get. You might duplicate some of the research the FX engineers > are doing but you also might not, or you might find yourself being able to > influence the direction of the project with unique input. > > If you can make WebGL work in WebKit, I guess it's not much harder to > expose an eGL binding via JavaFX itself as WebGL is basically eGL for the > web. > > I'd like to see GL support in JavaFX, if only because I enjoy blinging apps > I write, including business apps! The embedded video player is invaluable > for this sort of thing too. > > 1. Why wasn't WebGL support implemented from day zero given that WebKit >> supports it? >> > > I am going to take a stab at these answers based on my relatively poor > understanding of how JavaFX works. Answers worth what you paid for them. > > I'm going to guess that the answer is Windows. > > WebKit drawing is routed via the FX rendering layer, which is in turn an > abstraction over OpenGL and Direct3D on Windows. Mapping OpenGL to Direct3D > is a tricky problem that requires a sophisticated rendering layer. In order > to make WebGL happen, Google had to do a deal with a company called > TransGaming that had developed a translation layer between OpenGL and > Direct3D. That layer is called ANGLE and Google open sourced it once they > had acquired the rights. > > https://chromium.googlesource.com/angle/angle/+/master/README.md > > To support OpenGL in Java, you have two choices: > > 1) Directly expose the operating system underlying OpenGL driver. > > 2) Emulate GL on top of whatever the OS provides. > > Whenever you see OpenGL being used in Java today, the path taken is (1). > The reason browsers use the rather odd and indirect path of number (2) is > that on Windows OpenGL is not the native drawing layer, unlike MacOS and > Linux, games do not typically use OpenGL and as such the GL drivers are > often low quality, low performance and buggy. The GL driver situation is so > poor that it is basically never a good idea to use anything other than > DirectX on Windows. I suspect this is why JavaFX uses a dedicated Direct3D > backend on Windows: > > http://grepcode.com/file/repo1.maven.org/maven2/net.java.openjfx.backport/openjfx-78-backport/1.8.0-ea-b96.1/com/sun/prism/d3d/D3DPipeline.java > > >> 2. Is there some significant technical issue that makes WebGL >> implementation particularly difficult? >> > > Yes. See above. > > >> 3. What is a brief overview of the work that needs to be done? >> > > To expose WebGL, you have to do what Chrome does and map GL to Direct3D > using ANGLE. That's probably a fairly major engineering effort and requires > the complete import of a new open source subsystem into FX. > > Note that if you do this, it'd be silly to restrict it to WebGL in WebView! > You might as well expose a new JavaFX control that implements eGL at the > same time, as a first step towards competing the work. That in turn would > reduce the demand for WebGL because once you can do low level 3D graphics > from Java directly, you don't need to go through WebKit. It'd only be > needed for sites like Maps. > > Ultimately, I think it will be "fatal" if we have to wait another 4 years >> or so for Java 10 to get features that are already well developed in the >> competitor products. >> > > See the recent announcement by the lead Java architect that they want to > speed up Java releases. They definitely don't want a 4 year wait for Java > 10: > > https://mreinhold.org/blog/forward-faster > > I'd suggest getting started by exploring ANGLE and reading their > documentation and presentation materials. The path to WebGL or any form of > GL in JavaFX lies through ANGLE. > On 10 Sep 2017, at 02:51, Sten Nordstrom wrote: > > Having done some GL work on windows I've to
Re: WebView and WebGL
Thanks Michael - yes I have, and, extensively evaluated it. It's major problem is that it is a *heavyweight* component using native Chromium rendering. It's fast, supports WebGL but doesn't play nicely with the lightweight JavaFX controls. Anything rendered on top of it for example will not be visible. It's not a valid swap-in for lightweight WebView. They offer a lightweight "mode" for JxBrowser but all it does is render into an offscreen buffer and then use that as an image in JavaFX. It's very slow, maxes-out CPU utilisation and they had to implement an event handler delegate (which is feature deficient), and... it doesn't support WebGL in this mode!!! We need to add WebGL support to a lightweight Web View (be it based on WebKit or Chromium) > On 8 Sep 2017, at 21:15, Michael Paus wrote: > > I can't give you any more feedback than to say that I'd very much appreciate > such an effort. > Are you aware of this project/product? https://www.teamdev.com/jxbrowser > Michael > >> Am 08.09.17 um 12:54 schrieb John-Val Rose: >> This is a genuinely serious issue and a genuinely sincere offer of helping >> as much as I can. >> >> Some response would be greatly appreciated... >> >>> On 6 Sep 2017, at 16:53, John-Val Rose wrote: >>> >>> Getting back to the original issue, it's good to know that work is being >>> done to implement WebGL support but I fear that the whole process will take >>> longer than is really needed. >>> >>> As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX >>> lags behind Qt in features and performance as they basically had a 20 year >>> head start! >>> >>> But they do have a WebView with WebGL support and very advanced 3D features >>> in general (like a 3D Canvas). For JavaFX, it looks as though the 3D >>> features have been "unofficially deprecated" as no enhancements are planned >>> for JFX 10 and the existing features are rudimentary at best. >>> >>> But... just getting WebView to support WebGL instantly gives JavaFX >>> advanced 3D features via the multitude of WebGL libraries such as three.js >>> etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. >>> >>> Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf >>> is widening at a rapid pace. >>> >>> Could someone please try to answer the following questions so I can get a >>> better handle on where we are and what needs to be done: >>> >>> 1. Why wasn't WebGL support implemented from day zero given that WebKit >>> supports it? >>> >>> 2. Is there some significant technical issue that makes WebGL >>> implementation particularly difficult? >>> >>> 3. What is a brief overview of the work that needs to be done? >>> >>> I ask because (as I said), I am willing to work on this feature with as >>> much spare time as I can find and am keen to get going ASAP. >>> >>> And it's not just a WebGL problem per se as the current WebView only >>> supports Google Maps (one of the world's top websites) in Lite Mode which >>> again limits the potential quite badly. >>> >>> I hope these issues are related and can be addressed simultaneously. >>> >>> Ultimately, I think it will be "fatal" if we have to wait another 4 years >>> or so for Java 10 to get features that are already well developed in the >>> competitor products. >>> >>> Graciously, >>> >>> John-Val Rose >>> Rosethorn Technology >>> >>>> On 26 Aug 2017, at 23:46, Scott Palmer wrote: >>>> >>>> +1 >>>> >>>> ... to Any high performance way to get images from native code to the >>>> screen in a JavaFX app. I filed an enhancement request many years ago for >>>> a method to supply portions of the media pipeline for the media player >>>> APIs. >>>> >>>> I've also been asking for some way to get at a native surface context. Be >>>> it DirectX, OpenGL, Metal,... even just a native window handle. >>>> >>>> >>>> Scott >>>> >>>>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >>>>> >>>>> Hi Michael, all, >>>>> >>>>> Just want to state my support for Michael's "Direct backed WritableImage". >>>>>
Re: WebView and WebGL
This is a genuinely serious issue and a genuinely sincere offer of helping as much as I can. Some response would be greatly appreciated... > On 6 Sep 2017, at 16:53, John-Val Rose wrote: > > Getting back to the original issue, it's good to know that work is being done > to implement WebGL support but I fear that the whole process will take longer > than is really needed. > > As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX > lags behind Qt in features and performance as they basically had a 20 year > head start! > > But they do have a WebView with WebGL support and very advanced 3D features > in general (like a 3D Canvas). For JavaFX, it looks as though the 3D > features have been "unofficially deprecated" as no enhancements are planned > for JFX 10 and the existing features are rudimentary at best. > > But... just getting WebView to support WebGL instantly gives JavaFX advanced > 3D features via the multitude of WebGL libraries such as three.js etc. and > the urgency for a dedicated 3D Canvas would be greatly reduced. > > Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is > widening at a rapid pace. > > Could someone please try to answer the following questions so I can get a > better handle on where we are and what needs to be done: > > 1. Why wasn't WebGL support implemented from day zero given that WebKit > supports it? > > 2. Is there some significant technical issue that makes WebGL implementation > particularly difficult? > > 3. What is a brief overview of the work that needs to be done? > > I ask because (as I said), I am willing to work on this feature with as much > spare time as I can find and am keen to get going ASAP. > > And it's not just a WebGL problem per se as the current WebView only supports > Google Maps (one of the world's top websites) in Lite Mode which again limits > the potential quite badly. > > I hope these issues are related and can be addressed simultaneously. > > Ultimately, I think it will be "fatal" if we have to wait another 4 years or > so for Java 10 to get features that are already well developed in the > competitor products. > > Graciously, > > John-Val Rose > Rosethorn Technology > >> On 26 Aug 2017, at 23:46, Scott Palmer wrote: >> >> +1 >> >> ... to Any high performance way to get images from native code to the screen >> in a JavaFX app. I filed an enhancement request many years ago for a method >> to supply portions of the media pipeline for the media player APIs. >> >> I've also been asking for some way to get at a native surface context. Be it >> DirectX, OpenGL, Metal,... even just a native window handle. >> >> >> Scott >> >>> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >>> >>> Hi Michael, all, >>> >>> Just want to state my support for Michael's "Direct backed WritableImage". >>> Having a way to do natively-backed rendering is IMO the most important >>> feature still missing from FX. This is an area where QT is still way ahead >>> with it's OpenGL/OpenGL ES integration. >>> >>> Having something like a direct-WritableImage implementation would also make >>> it easier to implement a video viewer using native decoder libs. Personally >>> I find this approach much more powerful than the existing FX 3D and media >>> streaming features, which are (especially 3D) limited in their >>> capabilities. >>> >>> I will be at JavaOne this year, so if there is any interest in meeting up >>> and talking JavaFX I'm in! >>> >>> Best regards, >>> >>> Sten Nordström >>> >>>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>>> >>>> Hi Jonathan, hi all, >>>> >>>> I would like to bring up the "WritableImage backed by DirectBuffer" >>>> discussion again: >>>>
Re: Support additional video codec and container format
+1 > On 8 Sep 2017, at 19:05, Sverre Moe wrote: > > Why is JavaFX not supporting open video container and codec? > From Java 9 VP6 is deprecated. > > The only relevant supported coded for JavaFX is H.264/AVC. The only other > alternative is VP6 which has been deprecated in Java 9. > > We cannot use H.264 without paying lisence fee for a commercial application. > > Support for Ogg Theroa/Vorbis should be considered, at least VP8 and/or VP9 > in place for the deprecated VP6. The MediaPlayer for Java 10 has not gotten > any changes either. I reckon it is too late for Java 9 to get new formats.
Re: WebView and WebGL
Getting back to the original issue, it's good to know that work is being done to implement WebGL support but I fear that the whole process will take longer than is really needed. As I see it, JavaFX has one major competitor which is Qt. Naturally JavaFX lags behind Qt in features and performance as they basically had a 20 year head start! But they do have a WebView with WebGL support and very advanced 3D features in general (like a 3D Canvas). For JavaFX, it looks as though the 3D features have been "unofficially deprecated" as no enhancements are planned for JFX 10 and the existing features are rudimentary at best. But... just getting WebView to support WebGL instantly gives JavaFX advanced 3D features via the multitude of WebGL libraries such as three.js etc. and the urgency for a dedicated 3D Canvas would be greatly reduced. Further, Chromium (as used by Qt) is about to support WebGL 2 so the gulf is widening at a rapid pace. Could someone please try to answer the following questions so I can get a better handle on where we are and what needs to be done: 1. Why wasn't WebGL support implemented from day zero given that WebKit supports it? 2. Is there some significant technical issue that makes WebGL implementation particularly difficult? 3. What is a brief overview of the work that needs to be done? I ask because (as I said), I am willing to work on this feature with as much spare time as I can find and am keen to get going ASAP. And it's not just a WebGL problem per se as the current WebView only supports Google Maps (one of the world's top websites) in Lite Mode which again limits the potential quite badly. I hope these issues are related and can be addressed simultaneously. Ultimately, I think it will be "fatal" if we have to wait another 4 years or so for Java 10 to get features that are already well developed in the competitor products. Graciously, John-Val Rose Rosethorn Technology > On 26 Aug 2017, at 23:46, Scott Palmer wrote: > > +1 > > ... to Any high performance way to get images from native code to the screen > in a JavaFX app. I filed an enhancement request many years ago for a method > to supply portions of the media pipeline for the media player APIs. > > I've also been asking for some way to get at a native surface context. Be it > DirectX, OpenGL, Metal,... even just a native window handle. > > > Scott > >> On Aug 26, 2017, at 9:15 AM, Sten Nordstrom wrote: >> >> Hi Michael, all, >> >> Just want to state my support for Michael's "Direct backed WritableImage". >> Having a way to do natively-backed rendering is IMO the most important >> feature still missing from FX. This is an area where QT is still way ahead >> with it's OpenGL/OpenGL ES integration. >> >> Having something like a direct-WritableImage implementation would also make >> it easier to implement a video viewer using native decoder libs. Personally >> I find this approach much more powerful than the existing FX 3D and media >> streaming features, which are (especially 3D) limited in their >> capabilities. >> >> I will be at JavaOne this year, so if there is any interest in meeting up >> and talking JavaFX I'm in! >> >> Best regards, >> >> Sten Nordström >> >>> On Fri, 25 Aug 2017 at 22.41 Michael Hoffer wrote: >>> >>> Hi Jonathan, hi all, >>> >>> I would like to bring up the "WritableImage backed by DirectBuffer" >>> discussion again: >>>
Re: WebView and WebGL
Thanks for your input Jonathan - it's great to know that planning is happening. I'll be around if those involved ever wish to speak with me regarding how much time/effort I can contribute. On the subject of rendering, is there some way to confirm for certain that it is using the JavaFX API and not native WebKit rendering? This is of importance to me in relation to a slightly different issue. Thanks to both Michaels too for your informative input. Graciously, John-Val Rose > On 26 Aug 2017, at 05:41, Michael wrote: > > Hi Jonathan, hi all, > > I would like to bring up the "WritableImage backed by DirectBuffer" > discussion again: > > I did my own experiments with WebGL and native rendering. I posted them a > while ago here on the mailing list (https://github.com/miho/VFXWebKit & > https://youtu.be/FlIrY1SlNM4). I came to the conclusion that the most > generic and most important feature that we need for JavaFX is efficient > native buffer support (basically WritableImage backed by DirectBuffer). > This allows for plugging in almost any external rendering technology and > does not involve large API redesigns. Adding OpenGL and/or WebGL could be > done as community projects. > > I find it particularly elegant to spawn separate render processes for doing > OpenGL/WebGL. This is basically what modern browsers do. WebKit is a very > complex piece of software that isn't easy to handle. In the past I had too > many bad experiences with WebKit and JavaFX. WebKit could easily tear down > the whole JVM. None of the safety-belts usually provided by Java will help > in such a case. > > I would like to suggest that we do a JavaFX meeting at JavaOne for > discussing this topic. Anyone interested? > > Regards, > Michael > > > -- > Dr. rer. nat. Michael Hoffer > > Twitter: @mihosoft > Webpage: www.mihosoft.eu > > Oracle Developer Champion > > Goethe-Zentrum für Wissenschaftliches Rechnen (G-CSC) > Goethe-Universität > Kettenhofweg 139 > 60325 Frankfurt am Main > phone: +49 69 798 25254 > i...@michaelhoffer.de > > 2017-08-25 21:06 GMT+02:00 Jonathan Giles : > >> All, >> >> WebGL is something that is currently in the planning pipeline with a >> relatively high priority. This means it is not under active development >> yet, but we already have engineers working on the research towards this >> feature. Once this is concluded and the scope of the work better >> understood, a JEP will be filed to engage the community on this project, >> and notification will be sent to the openjfx-dev mailing list. >> >> In reference to the question on whether WebView uses WebKit rendering or >> JavaFX rendering, I believe the answer is the latter. >> >> -- Jonathan >> >> >> >>> On 25/08/17 12:12 PM, John-Val Rose wrote: >>> >>> I have a couple of questions about the implementation of WebView within >>> JavaFX. >>> >>> I understand that, at present, it is based on WebKit but does not support >>> WebGL. For our requirements, WebGL support is essential and I expect that >>> other developers would appreciate support of this kind as well. >>> >>> It appears that WebGL support will not be implemented until Java 10 at the >>> earliest, or, perhaps even later. As we know, this could be several years >>> away so I would like to offer my time to work on implementing WebGL >>> support >>> ASAP so that it can be released to the community as part of an incremental >>> Java 9 release. >>> >>> How do you feel about this suggestion? >>> >>> Also, could you please let me know that if the current WebView is just a >>> wrapper around WebKit and uses native WebKit rendering, or is it actually >>> using the JavaFX API itself to do the rendering within the JavaFX >>> rendering >>> pipeline? >>> >>> *Graciously,* >>> >>> *John-Val Rose* >>> *Chief Scientist/Architect* >>> *Rosethorn Technology* >>> *Australia* >>> >> >>
Re: WebView and WebGL
This *is* the problem: 7 years since a formal issue is raised and still we have nothing. As I said, WebGL support won't happen unless *we* make it happen and I'm in a position where I have both a need and time to work on it. I'm sure others would help too. Once someone from Oracle responds to my original questions, we will have a better idea of what the future holds. > On 26 Aug 2017, at 02:22, Nir Lisker wrote: > > It has been suggested already in > https://bugs.openjdk.java.net/browse/JDK-8091035.
Re: WebView and WebGL
I agree with you Michael. So let's open a discussion as a community and actually get coding. It won't happen otherwise... (At least not for 4 years or so) > On 25 Aug 2017, at 17:34, Michael Paus wrote: > > I also find it important to get WebGL support into WebView as soon as possible > but I fear that this is not such an easy task because there are a few things > to consider. From my point of view, for example, it would not make much sense > to implement WebGL exclusively in the context of the WebView. JavaFX > itself also needs some high-performance, cross-platform low-level rendering > engine which should be compatible with WebGL in a similar way as the JavaFX > Canvas is compatible with the HTML 5 Canvas. But once you have such a > cross-platform, GL compatible rendering engine you have to ask yourself why > JavaFX still needs different internal Prism renderer implementations and would > not just use the one cross platform engine. All this needs careful > consideration. > > Michael > >> Am 25.08.17 um 02:12 schrieb John-Val Rose: >> I have a couple of questions about the implementation of WebView within >> JavaFX. >> >> I understand that, at present, it is based on WebKit but does not support >> WebGL. For our requirements, WebGL support is essential and I expect that >> other developers would appreciate support of this kind as well. >> >> It appears that WebGL support will not be implemented until Java 10 at the >> earliest, or, perhaps even later. As we know, this could be several years >> away so I would like to offer my time to work on implementing WebGL support >> ASAP so that it can be released to the community as part of an incremental >> Java 9 release. >> >> How do you feel about this suggestion? >> >> Also, could you please let me know that if the current WebView is just a >> wrapper around WebKit and uses native WebKit rendering, or is it actually >> using the JavaFX API itself to do the rendering within the JavaFX rendering >> pipeline? >> >> *Graciously,* >> >> *John-Val Rose* >> *Chief Scientist/Architect* >> *Rosethorn Technology* >> *Australia* > >
WebView and WebGL
I have a couple of questions about the implementation of WebView within JavaFX. I understand that, at present, it is based on WebKit but does not support WebGL. For our requirements, WebGL support is essential and I expect that other developers would appreciate support of this kind as well. It appears that WebGL support will not be implemented until Java 10 at the earliest, or, perhaps even later. As we know, this could be several years away so I would like to offer my time to work on implementing WebGL support ASAP so that it can be released to the community as part of an incremental Java 9 release. How do you feel about this suggestion? Also, could you please let me know that if the current WebView is just a wrapper around WebKit and uses native WebKit rendering, or is it actually using the JavaFX API itself to do the rendering within the JavaFX rendering pipeline? *Graciously,* *John-Val Rose* *Chief Scientist/Architect* *Rosethorn Technology* *Australia*