Re: error in tutorial

[John-Val Rose]

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]

[John-Val Rose]

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?

[John-Val Rose]

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?

[John-Val Rose]

+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

[John-Val Rose]

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:
>>>>>> 
>>>>>> Yes, I meant removing charts f

Re: Has any consideration been made to move the Charts into s separate module?

[John-Val Rose]

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?

[John-Val Rose]

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?

[John-Val Rose]

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?

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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?

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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?

[John-Val Rose]

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?

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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

[John-Val Rose]

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 <johan@gluonhq.com> 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 <kevin.rushfo...@oracle.com>
> 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

[John-Val Rose]

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

[John-Val Rose]

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:
 
 

Re: More community participation in JavaFX

[John-Val Rose]

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 

Re: future content of OpenJFX

[John-Val Rose]

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 <j...@status6.com> 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

[John-Val Rose]

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 <sdes...@icloud.com> 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 <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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 <johan@gluonhq.com> wr

Re: future content of OpenJFX

[John-Val Rose]

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 

Re: More community participation in JavaFX

[John-Val Rose]

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

[John-Val Rose]

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 <sdes...@icloud.com> wrote:
> 
> Yes,  probably me.
> 
> Sent from iCloud
> 
>> On Feb 03, 2018, at 09:35 PM, John-Val Rose <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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 <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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 br

Re: More community participation in JavaFX

[John-Val Rose]

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 <sdes...@icloud.com> 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 <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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

Re: More community participation in JavaFX

[John-Val Rose]

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 <sdes...@icloud.com> 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 <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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

Re: More community participation in JavaFX

[John-Val Rose]

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 <sdes...@icloud.com> 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 <johnvalr...@gmail.com> 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 <sdes...@icloud.com> 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 <kevin.rushfo...@oracle.com> 
>>> > 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

[John-Val Rose]

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 <sdes...@icloud.com> 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 <kevin.rushfo...@oracle.com>
> 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

[John-Val Rose]

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 <rstei...@ensemblesoft.net> 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, 
>> especial

Re: Innovation “essay”

[John-Val Rose]

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)

[John-Val Rose]

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 <cnewl...@chrisnewland.com>
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, Michael, Jens, Jose, ... actually the more I
> think about it the longer this list gets) who s

Re: Innovation again (was Re: Text classes)

[John-Val Rose]

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 <johnvalr...@gmail.com> 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 <philip.r...@oracle.com> 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?
> >>
> >>> 

Re: Innovation again (was Re: Text classes)

[John-Val Rose]

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 <mar...@headcrashing.eu> 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 <mar...@headcrashing.eu> 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<philip.r...@oracle.com>  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

Re: Innovation again (was Re: Text classes)

[John-Val Rose]

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 <philip.r...@oracle.com> 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<philip.r...@oracle.com>  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
>>>> 
>>>&g

Re: Innovation again (was Re: Text classes)

[John-Val Rose]

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 <philip.r...@oracle.com> 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)

[John-Val Rose]

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: JavaOne slides about Marlin/FX renderer

[John-Val Rose]

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 <bourges.laur...@gmail.com>
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

[John-Val Rose]

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 <phidia...@gmail.com> 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
> development and mobile developmen

Re: OpenJFX initiative

[John-Val Rose]

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 <nlis...@gmail.com> 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 <johnvalr...@gmail.com>
> 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 <nlis...@gmail.com> 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 <johnvalr...@gmail.com>
>>> 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 firstl

Re: OpenJFX initiative

[John-Val Rose]

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 <nlis...@gmail.com> 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 <johnvalr...@gmail.com>
> 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 <nlis...@gmail.com> 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

[John-Val Rose]

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 <nlis...@gmail.com> 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

[John-Val Rose]

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 <j.tosov...@email.cz> 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)

[John-Val Rose]

Well, you would certainly know - thanks.

That's very encouraging :-)

> On 11 Sep 2017, at 20:02, Johan Vos <johan@gluonhq.com> 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 <johnvalr...@gmail.com> 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 <nlis...@gmail.com> 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 <johnvalr...@gmail.com>
>> > 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
>> > l

Re: Innovation (Was: WebView and WebGL)

[John-Val Rose]

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 <nlis...@gmail.com> 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 <johnvalr...@gmail.com>
> 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 <johnvalr...@gmail.com>
> 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 su

Innovation (Was: WebView and WebGL)

[John-Val Rose]

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 <nlis...@gmail.com> 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

[John-Val Rose]

...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

[John-Val Rose]

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 <swpal...@gmail.com> 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 <m...@plan99.net> 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

[John-Val Rose]

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 <m...@plan99.net> 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 <stnordst...@gmail.com> wrote:
> 
> Having done some GL work on windows I've to agree with Mike. Windows GL
> driver

Re: WebView and WebGL

[John-Val Rose]

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 <swpal...@gmail.com> 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 <stnordst...@gmail.com> 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 <i...@michaelhoffer.de> wrote:
>>> 
>>> Hi Jonathan, hi all,
>>> 
>>> I would like to bring up the "WritableImage backed by DirectBuffer"
>>> discussion again:
>>> 

Re: WebView and WebGL

[John-Val Rose]

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

[John-Val Rose]

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 <m...@jugs.org> 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*
> 
>