From johan.vos at gluonhq.com  Tue Oct  2 09:36:15 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Tue, 2 Oct 2018 11:36:15 +0200
Subject: A mailinglist for general JavaFX related discussions
Message-ID: <CABxFH2Ht+u-8+5pa2kFWm_5EAHJ+p8qKdKNMxSr+oHABegfN+A@mail.gmail.com>

Hi,

Welcome to the new mailinglist related to JavaFX:
openjfx-discuss at openjdk.java.net <openjfx-interest at openjdk.java.net> (manage
subscriptions via http://mail.openjdk.java.net/mailman/listinfo)

The reason this list is created, is to allow individuals and companies,
developers and managers, consumers and providers, to discuss their
ideas/experiences/suggestions related to JavaFX.

This list has a different purpose than the openjfx-dev at openjdk.java.net mailing
list, which is focused on the OpenJFX code, bugs and features.

There is sometimes a blurry line between the two, but in general, technical
discussions should happen at openjfx-dev while general discussions should
take place at openjfx-discuss.

Please avoid cross-posting in the two lists. In case of doubt, the
openjfx-discuss list is most likely the most appropriate one.

With this new list, we hope to see more stakeholders actively joining the
OpenJFX community.

Welcome, and thanks,

- Johan

From johan.vos at gluonhq.com  Wed Oct  3 08:56:45 2018
From: johan.vos at gluonhq.com (Johan Vos)
Date: Wed, 3 Oct 2018 10:56:45 +0200
Subject: priorities
Message-ID: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>

Every now and then people ask about the roadmap of JavaFX. Apart from my
general answer that the roadmap is mainly determined by the people who
contribute, here are some personal thoughts:

* JavaFX can be used in a large number of vertical markets, with totally
different requirements. We should be careful not to introduce
API's/features that make JavaFX a conflicting component in some markets.

* There are a number of third party libraries/frameworks (e.g. ControlsFX,
FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
functionality. I think OpenJFX has to provide the foundation for these
specific frameworks, rather than include their functionality.

* hardware accelerated rendering is key. We have to keep up with recent and
future evolutions.

* cross-platform is key.

In summary, I think that we have to make sure that JavaFX provides the most
performant rendering, and the most useful API allowing third parties to
create libraries and applications on a variety of platforms.

- Johan

From johnvalrose at gmail.com  Wed Oct  3 09:08:43 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Wed, 3 Oct 2018 19:08:43 +1000
Subject: priorities
In-Reply-To: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
Message-ID: <8E465626-B451-470C-B262-80EB9C8D5629@gmail.com>

+1

Everything you stated is what I also believe.

I think there really needs to be work done on performance, especially with the scene graph.

As for keeping-up with the latest technologies, I truly believe that WebGL, WebAssembly, Angle, Metal, & Vulkan need to be looked at seriously.

I think WebGL (or a switch to using Chromium instead of WebKit) is of the greatest important, even if for no other reason than to permit JavaFX to make full use of Google Maps.

And I?d just like to thank you personally Johan for all the incredible work you and your Gluon colleagues have put in to not only keeping JavaFX alive but to really guide and inspire all of us to use and contribute to OpenJFX.

Graciously,

John-Val Rose
Rosethorn Technology

> On 3 Oct 2018, at 18:56, Johan Vos <johan.vos at gluonhq.com> wrote:
> 
> Every now and then people ask about the roadmap of JavaFX. Apart from my
> general answer that the roadmap is mainly determined by the people who
> contribute, here are some personal thoughts:
> 
> * JavaFX can be used in a large number of vertical markets, with totally
> different requirements. We should be careful not to introduce
> API's/features that make JavaFX a conflicting component in some markets.
> 
> * There are a number of third party libraries/frameworks (e.g. ControlsFX,
> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
> functionality. I think OpenJFX has to provide the foundation for these
> specific frameworks, rather than include their functionality.
> 
> * hardware accelerated rendering is key. We have to keep up with recent and
> future evolutions.
> 
> * cross-platform is key.
> 
> In summary, I think that we have to make sure that JavaFX provides the most
> performant rendering, and the most useful API allowing third parties to
> create libraries and applications on a variety of platforms.
> 
> - Johan

From tom.schindl at bestsolution.at  Wed Oct  3 09:17:36 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 3 Oct 2018 11:17:36 +0200
Subject: priorities
In-Reply-To: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
Message-ID: <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>

Hi,

For us (I speak for BestSolution and our customers who don't want their
name showing up in public :-(

The following things are imporant:
* Integration of Native-Rendering (OpenGL / DirectX / Metal) into JavaFX
  applications where all information is kept on GPU and never escapes
  that

* Performance (most importantly CSS)

Tom

On 03.10.18 10:56, Johan Vos wrote:
> Every now and then people ask about the roadmap of JavaFX. Apart from my
> general answer that the roadmap is mainly determined by the people who
> contribute, here are some personal thoughts:
> 
> * JavaFX can be used in a large number of vertical markets, with totally
> different requirements. We should be careful not to introduce
> API's/features that make JavaFX a conflicting component in some markets.
> 
> * There are a number of third party libraries/frameworks (e.g. ControlsFX,
> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
> functionality. I think OpenJFX has to provide the foundation for these
> specific frameworks, rather than include their functionality.
> 
> * hardware accelerated rendering is key. We have to keep up with recent and
> future evolutions.
> 
> * cross-platform is key.
> 
> In summary, I think that we have to make sure that JavaFX provides the most
> performant rendering, and the most useful API allowing third parties to
> create libraries and applications on a variety of platforms.
> 
> - Johan
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From dlemmermann at gmail.com  Wed Oct  3 09:30:52 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 3 Oct 2018 11:30:52 +0200
Subject: priorities
In-Reply-To: <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
Message-ID: <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>

I strongly agree with Tom and would like to add that the missing support for rich text display and rich text editing is what caused me by far the most problems in my last project. We actually had to use Swing for this part of the UI.

Rich text here: bold, italic, foreground, background color, sup, sub, different fonts, hyperlinks, images, tables.

Dirk

> Am 03.10.2018 um 11:17 schrieb Tom Schindl <tom.schindl at bestsolution.at>:
> 
> Hi,
> 
> For us (I speak for BestSolution and our customers who don't want their
> name showing up in public :-(
> 
> The following things are imporant:
> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into JavaFX
>  applications where all information is kept on GPU and never escapes
>  that
> 
> * Performance (most importantly CSS)
> 
> Tom
> 
> On 03.10.18 10:56, Johan Vos wrote:
>> Every now and then people ask about the roadmap of JavaFX. Apart from my
>> general answer that the roadmap is mainly determined by the people who
>> contribute, here are some personal thoughts:
>> 
>> * JavaFX can be used in a large number of vertical markets, with totally
>> different requirements. We should be careful not to introduce
>> API's/features that make JavaFX a conflicting component in some markets.
>> 
>> * There are a number of third party libraries/frameworks (e.g. ControlsFX,
>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
>> functionality. I think OpenJFX has to provide the foundation for these
>> specific frameworks, rather than include their functionality.
>> 
>> * hardware accelerated rendering is key. We have to keep up with recent and
>> future evolutions.
>> 
>> * cross-platform is key.
>> 
>> In summary, I think that we have to make sure that JavaFX provides the most
>> performant rendering, and the most useful API allowing third parties to
>> create libraries and applications on a variety of platforms.
>> 
>> - Johan
>> 
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck


From tom.schindl at bestsolution.at  Wed Oct  3 09:36:13 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 3 Oct 2018 11:36:13 +0200
Subject: priorities
In-Reply-To: <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
 <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
Message-ID: <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>

Hi,

I should add (I already talked about that on twitter, ...) that we are
actively working on a PoC for the primary issue I mentioned below but I
think the technical discussion has to happen on openjfx-dev mailing list.

Tom

On 03.10.18 11:30, Dirk Lemmermann wrote:
> I strongly agree with Tom and would like to add that the missing support for rich text display and rich text editing is what caused me by far the most problems in my last project. We actually had to use Swing for this part of the UI.
> 
> Rich text here: bold, italic, foreground, background color, sup, sub, different fonts, hyperlinks, images, tables.
> 
> Dirk
> 
>> Am 03.10.2018 um 11:17 schrieb Tom Schindl <tom.schindl at bestsolution.at>:
>>
>> Hi,
>>
>> For us (I speak for BestSolution and our customers who don't want their
>> name showing up in public :-(
>>
>> The following things are imporant:
>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into JavaFX
>>  applications where all information is kept on GPU and never escapes
>>  that
>>
>> * Performance (most importantly CSS)
>>
>> Tom
>>
>> On 03.10.18 10:56, Johan Vos wrote:
>>> Every now and then people ask about the roadmap of JavaFX. Apart from my
>>> general answer that the roadmap is mainly determined by the people who
>>> contribute, here are some personal thoughts:
>>>
>>> * JavaFX can be used in a large number of vertical markets, with totally
>>> different requirements. We should be careful not to introduce
>>> API's/features that make JavaFX a conflicting component in some markets.
>>>
>>> * There are a number of third party libraries/frameworks (e.g. ControlsFX,
>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
>>> functionality. I think OpenJFX has to provide the foundation for these
>>> specific frameworks, rather than include their functionality.
>>>
>>> * hardware accelerated rendering is key. We have to keep up with recent and
>>> future evolutions.
>>>
>>> * cross-platform is key.
>>>
>>> In summary, I think that we have to make sure that JavaFX provides the most
>>> performant rendering, and the most useful API allowing third parties to
>>> create libraries and applications on a variety of platforms.
>>>
>>> - Johan
>>>
>>
>> -- 
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From johnvalrose at gmail.com  Wed Oct  3 10:18:13 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Wed, 3 Oct 2018 20:18:13 +1000
Subject: priorities
In-Reply-To: <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
 <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
 <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>
Message-ID: <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>

I also agree that full-featured text editing functionality would be highly advantageous.

> On 3 Oct 2018, at 19:36, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Hi,
> 
> I should add (I already talked about that on twitter, ...) that we are
> actively working on a PoC for the primary issue I mentioned below but I
> think the technical discussion has to happen on openjfx-dev mailing list.
> 
> Tom
> 
>> On 03.10.18 11:30, Dirk Lemmermann wrote:
>> I strongly agree with Tom and would like to add that the missing support for rich text display and rich text editing is what caused me by far the most problems in my last project. We actually had to use Swing for this part of the UI.
>> 
>> Rich text here: bold, italic, foreground, background color, sup, sub, different fonts, hyperlinks, images, tables.
>> 
>> Dirk
>> 
>>> Am 03.10.2018 um 11:17 schrieb Tom Schindl <tom.schindl at bestsolution.at>:
>>> 
>>> Hi,
>>> 
>>> For us (I speak for BestSolution and our customers who don't want their
>>> name showing up in public :-(
>>> 
>>> The following things are imporant:
>>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into JavaFX
>>> applications where all information is kept on GPU and never escapes
>>> that
>>> 
>>> * Performance (most importantly CSS)
>>> 
>>> Tom
>>> 
>>>> On 03.10.18 10:56, Johan Vos wrote:
>>>> Every now and then people ask about the roadmap of JavaFX. Apart from my
>>>> general answer that the roadmap is mainly determined by the people who
>>>> contribute, here are some personal thoughts:
>>>> 
>>>> * JavaFX can be used in a large number of vertical markets, with totally
>>>> different requirements. We should be careful not to introduce
>>>> API's/features that make JavaFX a conflicting component in some markets.
>>>> 
>>>> * There are a number of third party libraries/frameworks (e.g. ControlsFX,
>>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
>>>> functionality. I think OpenJFX has to provide the foundation for these
>>>> specific frameworks, rather than include their functionality.
>>>> 
>>>> * hardware accelerated rendering is key. We have to keep up with recent and
>>>> future evolutions.
>>>> 
>>>> * cross-platform is key.
>>>> 
>>>> In summary, I think that we have to make sure that JavaFX provides the most
>>>> performant rendering, and the most useful API allowing third parties to
>>>> create libraries and applications on a variety of platforms.
>>>> 
>>>> - Johan
>>>> 
>>> 
>>> -- 
>>> Tom Schindl, CTO
>>> BestSolution.at EDV Systemhaus GmbH
>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>> 
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From nlisker at gmail.com  Wed Oct  3 11:37:02 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 3 Oct 2018 14:37:02 +0300
Subject: priorities
In-Reply-To: <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
 <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
 <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>
 <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>
Message-ID: <CA+0ynh_owmku3ZbAU-+Ei5JP=T8Hc0it_s4rXmAcx6y6kWTB0g@mail.gmail.com>

I'm having a deja vu :) This is going to be the same discussion that was on
openjfx-dev a while back.

I propose that we use the Wiki to keep track of ideas/wishes/directions so
that we won't need to bring it up each time. There are already old
discussion pages there [1]. For example, rich text [2].

I volunteer to do the janitorial duties with the aim of creating a clear
view at everything that was brought up in these discussions. My hope is
that it will serve as an agglomeration surface for contributors with
similar interests. I think that there is a merit to list the people who are
interested for each feature, if that's fine with everyone. This way it's
easier to form a team.

[1] https://wiki.openjdk.java.net/display/OpenJFX/Discussions
[2] https://wiki.openjdk.java.net/display/OpenJFX/Rich+Text

- Nir

On Wed, Oct 3, 2018 at 1:18 PM John-Val Rose <johnvalrose at gmail.com> wrote:

> I also agree that full-featured text editing functionality would be highly
> advantageous.
>
> > On 3 Oct 2018, at 19:36, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
> >
> > Hi,
> >
> > I should add (I already talked about that on twitter, ...) that we are
> > actively working on a PoC for the primary issue I mentioned below but I
> > think the technical discussion has to happen on openjfx-dev mailing list.
> >
> > Tom
> >
> >> On 03.10.18 11:30, Dirk Lemmermann wrote:
> >> I strongly agree with Tom and would like to add that the missing
> support for rich text display and rich text editing is what caused me by
> far the most problems in my last project. We actually had to use Swing for
> this part of the UI.
> >>
> >> Rich text here: bold, italic, foreground, background color, sup, sub,
> different fonts, hyperlinks, images, tables.
> >>
> >> Dirk
> >>
> >>> Am 03.10.2018 um 11:17 schrieb Tom Schindl <
> tom.schindl at bestsolution.at>:
> >>>
> >>> Hi,
> >>>
> >>> For us (I speak for BestSolution and our customers who don't want their
> >>> name showing up in public :-(
> >>>
> >>> The following things are imporant:
> >>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into
> JavaFX
> >>> applications where all information is kept on GPU and never escapes
> >>> that
> >>>
> >>> * Performance (most importantly CSS)
> >>>
> >>> Tom
> >>>
> >>>> On 03.10.18 10:56, Johan Vos wrote:
> >>>> Every now and then people ask about the roadmap of JavaFX. Apart from
> my
> >>>> general answer that the roadmap is mainly determined by the people who
> >>>> contribute, here are some personal thoughts:
> >>>>
> >>>> * JavaFX can be used in a large number of vertical markets, with
> totally
> >>>> different requirements. We should be careful not to introduce
> >>>> API's/features that make JavaFX a conflicting component in some
> markets.
> >>>>
> >>>> * There are a number of third party libraries/frameworks (e.g.
> ControlsFX,
> >>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
> >>>> functionality. I think OpenJFX has to provide the foundation for these
> >>>> specific frameworks, rather than include their functionality.
> >>>>
> >>>> * hardware accelerated rendering is key. We have to keep up with
> recent and
> >>>> future evolutions.
> >>>>
> >>>> * cross-platform is key.
> >>>>
> >>>> In summary, I think that we have to make sure that JavaFX provides
> the most
> >>>> performant rendering, and the most useful API allowing third parties
> to
> >>>> create libraries and applications on a variety of platforms.
> >>>>
> >>>> - Johan
> >>>>
> >>>
> >>> --
> >>> Tom Schindl, CTO
> >>> BestSolution.at EDV Systemhaus GmbH
> >>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >>
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>

From guy.abossolo.foh at scientificware.com  Wed Oct  3 11:49:48 2018
From: guy.abossolo.foh at scientificware.com (Abossolo Foh Guy)
Date: Wed, 03 Oct 2018 13:49:48 +0200
Subject: priorities
In-Reply-To: <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
 <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
 <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>
 <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>
Message-ID: <e450d79f44d9dd4d75d2a288cbfd3a86@scientificware.com>

Hi,

I'm also interested by adding Mathematic support to your list of 
features. I already do it with swing/text API.

I tried with TextArea but its document model is too simple to support 
that.
So I'm trying to port the swing document model to JavaFX. This work is 
in progress but I took a break to work on MathML issue in the JavaFX 
WebKit implementation.

Basing the work on swing/text with DOM could be very interresting for 
many persons who want to migrate to JavaFX.

As Johan said, some JavaFX applications already do this job :
By example Jordan Martinez posted a message on openjdk or openjfx mail 
list about RichTextFX, he was looking for a new maintener. Could a fork 
of this project integrate JavaFX ?

Best regards.

Guy.
-----------------------------
Le 2018-10-03 12:18, John-Val Rose a ?crit?:
> I also agree that full-featured text editing functionality would be
> highly advantageous.
> 
>> On 3 Oct 2018, at 19:36, Tom Schindl <tom.schindl at bestsolution.at> 
>> wrote:
>> 
>> Hi,
>> 
>> I should add (I already talked about that on twitter, ...) that we are
>> actively working on a PoC for the primary issue I mentioned below but 
>> I
>> think the technical discussion has to happen on openjfx-dev mailing 
>> list.
>> 
>> Tom
>> 
>>> On 03.10.18 11:30, Dirk Lemmermann wrote:
>>> I strongly agree with Tom and would like to add that the missing 
>>> support for rich text display and rich text editing is what caused me 
>>> by far the most problems in my last project. We actually had to use 
>>> Swing for this part of the UI.
>>> 
>>> Rich text here: bold, italic, foreground, background color, sup, sub, 
>>> different fonts, hyperlinks, images, tables.
>>> 
>>> Dirk
>>> 
>>>> Am 03.10.2018 um 11:17 schrieb Tom Schindl 
>>>> <tom.schindl at bestsolution.at>:
>>>> 
>>>> Hi,
>>>> 
>>>> For us (I speak for BestSolution and our customers who don't want 
>>>> their
>>>> name showing up in public :-(
>>>> 
>>>> The following things are imporant:
>>>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into 
>>>> JavaFX
>>>> applications where all information is kept on GPU and never escapes
>>>> that
>>>> 
>>>> * Performance (most importantly CSS)
>>>> 
>>>> Tom
>>>> 
>>>>> On 03.10.18 10:56, Johan Vos wrote:
>>>>> Every now and then people ask about the roadmap of JavaFX. Apart 
>>>>> from my
>>>>> general answer that the roadmap is mainly determined by the people 
>>>>> who
>>>>> contribute, here are some personal thoughts:
>>>>> 
>>>>> * JavaFX can be used in a large number of vertical markets, with 
>>>>> totally
>>>>> different requirements. We should be careful not to introduce
>>>>> API's/features that make JavaFX a conflicting component in some 
>>>>> markets.
>>>>> 
>>>>> * There are a number of third party libraries/frameworks (e.g. 
>>>>> ControlsFX,
>>>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
>>>>> functionality. I think OpenJFX has to provide the foundation for 
>>>>> these
>>>>> specific frameworks, rather than include their functionality.
>>>>> 
>>>>> * hardware accelerated rendering is key. We have to keep up with 
>>>>> recent and
>>>>> future evolutions.
>>>>> 
>>>>> * cross-platform is key.
>>>>> 
>>>>> In summary, I think that we have to make sure that JavaFX provides 
>>>>> the most
>>>>> performant rendering, and the most useful API allowing third 
>>>>> parties to
>>>>> create libraries and applications on a variety of platforms.
>>>>> 
>>>>> - Johan
>>>>> 
>>>> 
>>>> --
>>>> Tom Schindl, CTO
>>>> BestSolution.at EDV Systemhaus GmbH
>>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>>> 
>> 
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

-- 

From dlemmermann at gmail.com  Wed Oct  3 11:54:46 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 3 Oct 2018 13:54:46 +0200
Subject: Rich Text Support
Message-ID: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>

(I am creating a new thread in order to avoid interfering with the ?priorities? thread).

I started looking at RichTextFX a while ago and must admit that its API was too academic for me to fully comprehend. It definitely was not following in the footsteps of the rest of the JavaFX API.

Dirk


From pedro.duquevieira at gmail.com  Wed Oct  3 12:21:33 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Wed, 3 Oct 2018 13:21:33 +0100
Subject: Rich Text Support
In-Reply-To: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
Message-ID: <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>

Hi,

Have you guys tried JavaFX TextFlow class and such for just the display
part of rich text?

Cheers,



On Wed, Oct 3, 2018 at 12:55 PM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> (I am creating a new thread in order to avoid interfering with the
> ?priorities? thread).
>
> I started looking at RichTextFX a while ago and must admit that its API
> was too academic for me to fully comprehend. It definitely was not
> following in the footsteps of the rest of the JavaFX API.
>
> Dirk
>
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From dlemmermann at gmail.com  Wed Oct  3 12:30:00 2018
From: dlemmermann at gmail.com (Dirk Lemmermann)
Date: Wed, 3 Oct 2018 14:30:00 +0200
Subject: Rich Text Support
In-Reply-To: <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
Message-ID: <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>

Of course ?. and that works fine. I really should have only mentioned ?editing?. Although it would also be nice to have a label with rich text support as part of the core JavaFX API. I developed a rich text label for one of my projects and might soon contribute it to ControlsFX or create an independent project on GitHub.

Dirk

> Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira <pedro.duquevieira at gmail.com>:
> 
> Hi,
> 
> Have you guys tried JavaFX TextFlow class and such for just the display part of rich text?
> 
> Cheers,
> 
> 
> 
> On Wed, Oct 3, 2018 at 12:55 PM Dirk Lemmermann <dlemmermann at gmail.com <mailto:dlemmermann at gmail.com>> wrote:
> (I am creating a new thread in order to avoid interfering with the ?priorities? thread).
> 
> I started looking at RichTextFX a while ago and must admit that its API was too academic for me to fully comprehend. It definitely was not following in the footsteps of the rest of the JavaFX API.
> 
> Dirk
> 
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com <https://www.pixelduke.com/>

From pedro.duquevieira at gmail.com  Wed Oct  3 12:50:16 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Wed, 3 Oct 2018 13:50:16 +0100
Subject: Rich Text Support
In-Reply-To: <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
Message-ID: <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>

Yeah, I just mentioned it to clear up the conversation. I knew you'd
probably know about it.

I've never actually implemented or tried to implement a full blown rich
text editor, so probably not the best person to discuss this but I did try
some simple stuff so here's my 2 cents:

I think to start, probably a class like Swing's FontMetrics would be good
to have? Before Java 9 there was one but it was private implementation.
Just to have the basic API that would allow to build rich text editing
support more easily, sorted out..
This is also, generally, needed for calculating how to lay out text.

Cheers,



On Wed, Oct 3, 2018 at 1:30 PM Dirk Lemmermann <dlemmermann at gmail.com>
wrote:

> Of course ?. and that works fine. I really should have only mentioned
> ?editing?. Although it would also be nice to have a label with rich text
> support as part of the core JavaFX API. I developed a rich text label for
> one of my projects and might soon contribute it to ControlsFX or create an
> independent project on GitHub.
>
> Dirk
>
> Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira <
> pedro.duquevieira at gmail.com>:
>
> Hi,
>
> Have you guys tried JavaFX TextFlow class and such for just the display
> part of rich text?
>
> Cheers,
>
>
>
> On Wed, Oct 3, 2018 at 12:55 PM Dirk Lemmermann <dlemmermann at gmail.com>
> wrote:
>
>> (I am creating a new thread in order to avoid interfering with the
>> ?priorities? thread).
>>
>> I started looking at RichTextFX a while ago and must admit that its API
>> was too academic for me to fully comprehend. It definitely was not
>> following in the footsteps of the rest of the JavaFX API.
>>
>> Dirk
>>
>>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From pedro.duquevieira at gmail.com  Wed Oct  3 13:22:31 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Wed, 3 Oct 2018 14:22:31 +0100
Subject: priorities
In-Reply-To: <e450d79f44d9dd4d75d2a288cbfd3a86@scientificware.com>
References: <CABxFH2G_+ibxxkHJEDh_0-b+n6Qd7kiQmQ3i9TSrrciVQfzpRg@mail.gmail.com>
 <d9247c1d-4cf0-570f-a7ec-0fe26a8e15ef@bestsolution.at>
 <6CE3F62F-881C-4257-9551-03EB570A77EB@gmail.com>
 <365bd762-b757-cd6c-1968-3e2158dc553a@bestsolution.at>
 <BE5DB30C-A938-44A9-AA92-07F760AE81EA@gmail.com>
 <e450d79f44d9dd4d75d2a288cbfd3a86@scientificware.com>
Message-ID: <CAAEud6ZMeQZ46w3p86KbcB6_sfm3kLKaAHmUg5vNNCp4HqP3ow@mail.gmail.com>

I agree with Johan: "the key is to provide the performant rendering, and
the most useful API allowing third parties to
create libraries and applications on a variety of platforms".

So my priorities for the JavaFX framework would be:

-> Performance

-> Extensibility.
Providing more hooks for third parties to override and extend the JavaFX
framework. For example allowing things like extending/overriding the CSS
parser (to add animation support for instance). A node that supports native
3D rendering like an OpenGL node, etc. Allowing third party libraries to
extend every aspect of JavaFX.
Another one is relaxing the constraints put up on the development of the
JavaFX API when it was part of the JDK. For example, I think that too many
classes, methods, fields are final and/or private. This hinders third
parties ability to extend the framework.

Cheers,



On Wed, Oct 3, 2018 at 12:50 PM Abossolo Foh Guy <
guy.abossolo.foh at scientificware.com> wrote:

> Hi,
>
> I'm also interested by adding Mathematic support to your list of
> features. I already do it with swing/text API.
>
> I tried with TextArea but its document model is too simple to support
> that.
> So I'm trying to port the swing document model to JavaFX. This work is
> in progress but I took a break to work on MathML issue in the JavaFX
> WebKit implementation.
>
> Basing the work on swing/text with DOM could be very interresting for
> many persons who want to migrate to JavaFX.
>
> As Johan said, some JavaFX applications already do this job :
> By example Jordan Martinez posted a message on openjdk or openjfx mail
> list about RichTextFX, he was looking for a new maintener. Could a fork
> of this project integrate JavaFX ?
>
> Best regards.
>
> Guy.
> -----------------------------
> Le 2018-10-03 12:18, John-Val Rose a ?crit :
> > I also agree that full-featured text editing functionality would be
> > highly advantageous.
> >
> >> On 3 Oct 2018, at 19:36, Tom Schindl <tom.schindl at bestsolution.at>
> >> wrote:
> >>
> >> Hi,
> >>
> >> I should add (I already talked about that on twitter, ...) that we are
> >> actively working on a PoC for the primary issue I mentioned below but
> >> I
> >> think the technical discussion has to happen on openjfx-dev mailing
> >> list.
> >>
> >> Tom
> >>
> >>> On 03.10.18 11:30, Dirk Lemmermann wrote:
> >>> I strongly agree with Tom and would like to add that the missing
> >>> support for rich text display and rich text editing is what caused me
> >>> by far the most problems in my last project. We actually had to use
> >>> Swing for this part of the UI.
> >>>
> >>> Rich text here: bold, italic, foreground, background color, sup, sub,
> >>> different fonts, hyperlinks, images, tables.
> >>>
> >>> Dirk
> >>>
> >>>> Am 03.10.2018 um 11:17 schrieb Tom Schindl
> >>>> <tom.schindl at bestsolution.at>:
> >>>>
> >>>> Hi,
> >>>>
> >>>> For us (I speak for BestSolution and our customers who don't want
> >>>> their
> >>>> name showing up in public :-(
> >>>>
> >>>> The following things are imporant:
> >>>> * Integration of Native-Rendering (OpenGL / DirectX / Metal) into
> >>>> JavaFX
> >>>> applications where all information is kept on GPU and never escapes
> >>>> that
> >>>>
> >>>> * Performance (most importantly CSS)
> >>>>
> >>>> Tom
> >>>>
> >>>>> On 03.10.18 10:56, Johan Vos wrote:
> >>>>> Every now and then people ask about the roadmap of JavaFX. Apart
> >>>>> from my
> >>>>> general answer that the roadmap is mainly determined by the people
> >>>>> who
> >>>>> contribute, here are some personal thoughts:
> >>>>>
> >>>>> * JavaFX can be used in a large number of vertical markets, with
> >>>>> totally
> >>>>> different requirements. We should be careful not to introduce
> >>>>> API's/features that make JavaFX a conflicting component in some
> >>>>> markets.
> >>>>>
> >>>>> * There are a number of third party libraries/frameworks (e.g.
> >>>>> ControlsFX,
> >>>>> FlexGanttFX, e(fx)clipse, Gluon Maps,...) that provide additional
> >>>>> functionality. I think OpenJFX has to provide the foundation for
> >>>>> these
> >>>>> specific frameworks, rather than include their functionality.
> >>>>>
> >>>>> * hardware accelerated rendering is key. We have to keep up with
> >>>>> recent and
> >>>>> future evolutions.
> >>>>>
> >>>>> * cross-platform is key.
> >>>>>
> >>>>> In summary, I think that we have to make sure that JavaFX provides
> >>>>> the most
> >>>>> performant rendering, and the most useful API allowing third
> >>>>> parties to
> >>>>> create libraries and applications on a variety of platforms.
> >>>>>
> >>>>> - Johan
> >>>>>
> >>>>
> >>>> --
> >>>> Tom Schindl, CTO
> >>>> BestSolution.at EDV Systemhaus GmbH
> >>>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >>>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> >>>
> >>
> >> --
> >> Tom Schindl, CTO
> >> BestSolution.at EDV Systemhaus GmbH
> >> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> >> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
> --
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From philip.race at oracle.com  Wed Oct  3 17:39:39 2018
From: philip.race at oracle.com (Phil Race)
Date: Wed, 3 Oct 2018 10:39:39 -0700
Subject: Rich Text Support
In-Reply-To: <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
Message-ID: <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>



On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
> I think to start, probably a class like Swing's FontMetrics would be good
> to have? Before Java 9 there was one but it was private implementation.
> Just to have the basic API that would allow to build rich text editing
> support more easily, sorted out..
> This is also, generally, needed for calculating how to lay out text.

I agree, and maybe I should aim to finally implement this in 12 :
https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text 
measurement API

-phil.

From nlisker at gmail.com  Wed Oct  3 18:03:35 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Wed, 3 Oct 2018 21:03:35 +0300
Subject: Rich Text Support
In-Reply-To: <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
Message-ID: <CA+0ynh9VbE6_Y_nMrFb7KSYDFQfC-1AM0XxmTPYa5Vgiygi56g@mail.gmail.com>

That would be great, Phil. It will serve much more than just rich text.

On Wed, Oct 3, 2018 at 8:40 PM Phil Race <philip.race at oracle.com> wrote:

>
>
> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
> > I think to start, probably a class like Swing's FontMetrics would be good
> > to have? Before Java 9 there was one but it was private implementation.
> > Just to have the basic API that would allow to build rich text editing
> > support more easily, sorted out..
> > This is also, generally, needed for calculating how to lay out text.
>
> I agree, and maybe I should aim to finally implement this in 12 :
> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
> measurement API
>
> -phil.
>

From tom.schindl at bestsolution.at  Wed Oct  3 18:08:51 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 3 Oct 2018 20:08:51 +0200
Subject: Rich Text Support
In-Reply-To: <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
Message-ID: <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>

Hi,

I fully agree and I don't think such a control should be part of the
OpenJFX but should live in an other library.

/me thinks OpenJFX should not get *ANY* new controls (I would even argue
that the current controls should be split out) but provide the core APIs
needed to implement them.

Tom

On 03.10.18 19:39, Phil Race wrote:
> 
> 
> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>> I think to start, probably a class like Swing's FontMetrics would be good
>> to have? Before Java 9 there was one but it was private implementation.
>> Just to have the basic API that would allow to build rich text editing
>> support more easily, sorted out..
>> This is also, generally, needed for calculating how to lay out text.
> 
> I agree, and maybe I should aim to finally implement this in 12 :
> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
> measurement API
> 
> -phil.

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From andrea.liana at ingliana.com  Thu Oct  4 12:41:34 2018
From: andrea.liana at ingliana.com (Andrea Liana)
Date: Thu, 4 Oct 2018 14:41:34 +0200
Subject: FontMetrics
Message-ID: <359565db-afef-4517-16bb-7963c2f5c595@ingliana.com>

Hello,

Its my first time I contribute to a mailing list, maybe not in proper 
way, but lets talk about Font Metrics.

I've been tinkering fro Java 8 with JavaFX and still I am.

I am working on framework in order to replace my old AWT/Swing based one 
in production.

About FontMetrics, it was one of the first problem I encountered when I 
built from scratch a new table component. Sorry for JavaFX, but the 
default one is quite hard to manage. To solve that, after digging all 
around, the easiest way to manage was to create an instance of 
javafx.scene.text.Text in the skin class and use it when calculating 
layout and text position.

The code looks like:

private final Texttext =new Text(); ....
text.setText(column._title); text.setFont(HeaderFont); final Bounds 
bounds = text.getLayoutBounds(); ... // Use bounds for text measurement...


Maybe its not the best or elegant way, but for the moment it works. In 
my opinion font measurements should be baked into the Font class 
directly instead of adding more classes.

Andrea Liana





From sverre.moe at gmail.com  Thu Oct  4 16:56:31 2018
From: sverre.moe at gmail.com (Sverre Moe)
Date: Thu, 4 Oct 2018 18:56:31 +0200
Subject: FontMetrics
In-Reply-To: <359565db-afef-4517-16bb-7963c2f5c595@ingliana.com>
References: <359565db-afef-4517-16bb-7963c2f5c595@ingliana.com>
Message-ID: <CALAJ+5BU9HciBNHN9mGnbO-05PQ4trM8yn9r_wzds-UReBZzTA@mail.gmail.com>

We are doing something similar to "calculate" the width of an Label in
JavaFX.

        final String name = nameLabel.getText();
        final Text text = new Text(name);
        new Scene(new Group(text));
        text.applyCss();
        double prefWidthVal = text.getLayoutBounds().getWidth();

JavaFX has FontMetrics, but it is private API.
com.sun.javafx.tk.FontMetrics;
com.sun.javafx.tk.Toolkit;

There is an 8 year old feature request for FontMetrics in JavaFX:
https://bugs.openjdk.java.net/browse/JDK-8090775

A public FontMetrics API would be very useful.

/Sverre

Den tor. 4. okt. 2018 kl. 14:42 skrev Andrea Liana <
andrea.liana at ingliana.com>:

> Hello,
>
> Its my first time I contribute to a mailing list, maybe not in proper
> way, but lets talk about Font Metrics.
>
> I've been tinkering fro Java 8 with JavaFX and still I am.
>
> I am working on framework in order to replace my old AWT/Swing based one
> in production.
>
> About FontMetrics, it was one of the first problem I encountered when I
> built from scratch a new table component. Sorry for JavaFX, but the
> default one is quite hard to manage. To solve that, after digging all
> around, the easiest way to manage was to create an instance of
> javafx.scene.text.Text in the skin class and use it when calculating
> layout and text position.
>
> The code looks like:
>
> private final Texttext =new Text(); ....
> text.setText(column._title); text.setFont(HeaderFont); final Bounds
> bounds = text.getLayoutBounds(); ... // Use bounds for text measurement...
>
>
> Maybe its not the best or elegant way, but for the moment it works. In
> my opinion font measurements should be baked into the Font class
> directly instead of adding more classes.
>
> Andrea Liana
>
>
>
>
>

From kevin.rushforth at oracle.com  Fri Oct  5 13:34:05 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 5 Oct 2018 06:34:05 -0700
Subject: Rich Text Support
In-Reply-To: <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
Message-ID: <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>

I agree that new controls, especially a RichText control, should very 
likely not be part of the core -- at least not at first. Somewhere like 
ControlsFX might be a great place to develop it. What we need to do is 
identify the missing pieces that prevent it from being implemented as an 
external control. The text measurement API is one such missing piece, 
but I'll bet there are others.

-- Kevin


On 10/3/2018 11:08 AM, Tom Schindl wrote:
> Hi,
>
> I fully agree and I don't think such a control should be part of the
> OpenJFX but should live in an other library.
>
> /me thinks OpenJFX should not get *ANY* new controls (I would even argue
> that the current controls should be split out) but provide the core APIs
> needed to implement them.
>
> Tom
>
> On 03.10.18 19:39, Phil Race wrote:
>>
>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>>> I think to start, probably a class like Swing's FontMetrics would be good
>>> to have? Before Java 9 there was one but it was private implementation.
>>> Just to have the basic API that would allow to build rich text editing
>>> support more easily, sorted out..
>>> This is also, generally, needed for calculating how to lay out text.
>> I agree, and maybe I should aim to finally implement this in 12 :
>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
>> measurement API
>>
>> -phil.


From johnvalrose at gmail.com  Fri Oct  5 19:59:22 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sat, 6 Oct 2018 05:59:22 +1000
Subject: Rich Text Support
In-Reply-To: <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
 <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
Message-ID: <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>

Kevin,

I am somewhat curious as to this idea that new JavaFX controls should not be part of the core toolkit.

Why do feel this way?

And I guess it begs the question: Why have *any* controls in the core of JavaFX at all?

Graciously,

John-Val Rose
Rosethorn Technology

> On 5 Oct 2018, at 23:34, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
> 
> I agree that new controls, especially a RichText control, should very likely not be part of the core -- at least not at first. Somewhere like ControlsFX might be a great place to develop it. What we need to do is identify the missing pieces that prevent it from being implemented as an external control. The text measurement API is one such missing piece, but I'll bet there are others.
> 
> -- Kevin
> 
> 
>> On 10/3/2018 11:08 AM, Tom Schindl wrote:
>> Hi,
>> 
>> I fully agree and I don't think such a control should be part of the
>> OpenJFX but should live in an other library.
>> 
>> /me thinks OpenJFX should not get *ANY* new controls (I would even argue
>> that the current controls should be split out) but provide the core APIs
>> needed to implement them.
>> 
>> Tom
>> 
>>> On 03.10.18 19:39, Phil Race wrote:
>>> 
>>>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>>>> I think to start, probably a class like Swing's FontMetrics would be good
>>>> to have? Before Java 9 there was one but it was private implementation.
>>>> Just to have the basic API that would allow to build rich text editing
>>>> support more easily, sorted out..
>>>> This is also, generally, needed for calculating how to lay out text.
>>> I agree, and maybe I should aim to finally implement this in 12 :
>>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
>>> measurement API
>>> 
>>> -phil.
> 

From kevin.rushforth at oracle.com  Fri Oct  5 20:32:25 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 5 Oct 2018 13:32:25 -0700
Subject: Rich Text Support
In-Reply-To: <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
 <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
 <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
Message-ID: <fa1daaeb-632f-1d37-642e-dc7efeb803b9@oracle.com>

Note that I did say "at least at first" when I was agreeing that it 
should likely not be part of the core. Developing a RichText control is 
going to be a big task that will likely take a bit of experimenting to 
get everything right. Doing that externally would allow for more rapid 
prototyping and testing before committing to a core API. If it becomes 
something that is generally considered useful, and fits well with the 
other controls, then I don't necessarily see a problem getting it into 
the core (although it would need to go through an feature review just 
like any new API). That was what we did for Alert and Spinner when they 
were first implemented; both needed a fair bit of additional work before 
bringing it into javafx.controls, but it was heavily leveraged by the 
work done in ControlsFX.

Btw, I might feel the same way about, say, DatePicker if we were 
developing it now. However, I do think that almost all of the current 
set fit within what I would expect a UI toolkit to provide as a default 
set of controls.

Johan might have a somewhat different take on this, so it would be good 
to get his thoughts.

-- Kevin


On 10/5/2018 12:59 PM, John-Val Rose wrote:
> Kevin,
>
> I am somewhat curious as to this idea that new JavaFX controls should not be part of the core toolkit.
>
> Why do feel this way?
>
> And I guess it begs the question: Why have *any* controls in the core of JavaFX at all?
>
> Graciously,
>
> John-Val Rose
> Rosethorn Technology
>
>> On 5 Oct 2018, at 23:34, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> I agree that new controls, especially a RichText control, should very likely not be part of the core -- at least not at first. Somewhere like ControlsFX might be a great place to develop it. What we need to do is identify the missing pieces that prevent it from being implemented as an external control. The text measurement API is one such missing piece, but I'll bet there are others.
>>
>> -- Kevin
>>
>>
>>> On 10/3/2018 11:08 AM, Tom Schindl wrote:
>>> Hi,
>>>
>>> I fully agree and I don't think such a control should be part of the
>>> OpenJFX but should live in an other library.
>>>
>>> /me thinks OpenJFX should not get *ANY* new controls (I would even argue
>>> that the current controls should be split out) but provide the core APIs
>>> needed to implement them.
>>>
>>> Tom
>>>
>>>> On 03.10.18 19:39, Phil Race wrote:
>>>>
>>>>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>>>>> I think to start, probably a class like Swing's FontMetrics would be good
>>>>> to have? Before Java 9 there was one but it was private implementation.
>>>>> Just to have the basic API that would allow to build rich text editing
>>>>> support more easily, sorted out..
>>>>> This is also, generally, needed for calculating how to lay out text.
>>>> I agree, and maybe I should aim to finally implement this in 12 :
>>>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
>>>> measurement API
>>>>
>>>> -phil.


From tom.schindl at bestsolution.at  Fri Oct  5 20:46:43 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Fri, 5 Oct 2018 22:46:43 +0200
Subject: Rich Text Support
In-Reply-To: <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
 <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
 <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
Message-ID: <03cc7ef2-bf37-2fdc-156a-de1f024eee69@bestsolution.at>

Hi,

I'm not Kevin but I'd like to outline my view.

To me there are multiple points:

* if it is part of the core the burden of maintenance (even if it is
  just to review changes produces by us externals) is put on the
  existing committers and the barrier to get those is high (which is a
  good thing IMHO)

* breaking changes (even small ones) are impossible to do

* treating a control as an external thing makes it easier to mix it with
  different versions of OpenJFX

* beside the simple standard controls (and even there) an API that
  pleases everyone is next to impossible to do

* Now that OpenJFX is "just" a library I don't see why getting part of
  it does make anything different to just adding another dependency. The
  only difference is IP-Checks, ...

I think the OpenJFX-Team should concentrate to provide the low-level
APIs to implement controls from TextField to TreeTable to RichText and
spend their time on that.

Tom

On 05.10.18 21:59, John-Val Rose wrote:
> Kevin,
> 
> I am somewhat curious as to this idea that new JavaFX controls should not be part of the core toolkit.
> 
> Why do feel this way?
> 
> And I guess it begs the question: Why have *any* controls in the core of JavaFX at all?
> 
> Graciously,
> 
> John-Val Rose
> Rosethorn Technology
> 
>> On 5 Oct 2018, at 23:34, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>>
>> I agree that new controls, especially a RichText control, should very likely not be part of the core -- at least not at first. Somewhere like ControlsFX might be a great place to develop it. What we need to do is identify the missing pieces that prevent it from being implemented as an external control. The text measurement API is one such missing piece, but I'll bet there are others.
>>
>> -- Kevin
>>
>>
>>> On 10/3/2018 11:08 AM, Tom Schindl wrote:
>>> Hi,
>>>
>>> I fully agree and I don't think such a control should be part of the
>>> OpenJFX but should live in an other library.
>>>
>>> /me thinks OpenJFX should not get *ANY* new controls (I would even argue
>>> that the current controls should be split out) but provide the core APIs
>>> needed to implement them.
>>>
>>> Tom
>>>
>>>> On 03.10.18 19:39, Phil Race wrote:
>>>>
>>>>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>>>>> I think to start, probably a class like Swing's FontMetrics would be good
>>>>> to have? Before Java 9 there was one but it was private implementation.
>>>>> Just to have the basic API that would allow to build rich text editing
>>>>> support more easily, sorted out..
>>>>> This is also, generally, needed for calculating how to lay out text.
>>>> I agree, and maybe I should aim to finally implement this in 12 :
>>>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
>>>> measurement API
>>>>
>>>> -phil.
>>

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From pedro.duquevieira at gmail.com  Fri Oct  5 20:51:36 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Fri, 5 Oct 2018 21:51:36 +0100
Subject: Rich Text Support
In-Reply-To: <fa1daaeb-632f-1d37-642e-dc7efeb803b9@oracle.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
 <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
 <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
 <fa1daaeb-632f-1d37-642e-dc7efeb803b9@oracle.com>
Message-ID: <CAAEud6bbNLqotLVW6D2n6RA2q3MeLZGdXVKbNXe1aNkrFFUZwg@mail.gmail.com>

I agree.

A UI framework needs at least a standard set of controls in its core. I'd
say at least 90% of UI apps being created need at least a couple of UI
controls.

I think we should focus on having a strong core library that would allow to
build additional controls, by at least third parties. Things like
FontMetrics like API are strongly needed, not just for Rich Text editor and
not just for UI controls and should be the priority. Other things that can
be built outside the openjfx, like a rich text editor, are nice to have but
not a priority.

I agree that things like rich text editors can be built outside first and
then integrated. I believe this is the best workflow has it allows for
prototyping,  experimenting,  getting feedback from users and iterating.
And when it has a pretty solid API and user experience it can be integrated
inside the openjfx library, because then things will get much more
complicated to change and break.

Cheers,

On Fri, Oct 5, 2018 at 9:32 PM Kevin Rushforth <kevin.rushforth at oracle.com>
wrote:

> Note that I did say "at least at first" when I was agreeing that it
> should likely not be part of the core. Developing a RichText control is
> going to be a big task that will likely take a bit of experimenting to
> get everything right. Doing that externally would allow for more rapid
> prototyping and testing before committing to a core API. If it becomes
> something that is generally considered useful, and fits well with the
> other controls, then I don't necessarily see a problem getting it into
> the core (although it would need to go through an feature review just
> like any new API). That was what we did for Alert and Spinner when they
> were first implemented; both needed a fair bit of additional work before
> bringing it into javafx.controls, but it was heavily leveraged by the
> work done in ControlsFX.
>
> Btw, I might feel the same way about, say, DatePicker if we were
> developing it now. However, I do think that almost all of the current
> set fit within what I would expect a UI toolkit to provide as a default
> set of controls.
>
> Johan might have a somewhat different take on this, so it would be good
> to get his thoughts.
>
> -- Kevin
>
>
> On 10/5/2018 12:59 PM, John-Val Rose wrote:
> > Kevin,
> >
> > I am somewhat curious as to this idea that new JavaFX controls should
> not be part of the core toolkit.
> >
> > Why do feel this way?
> >
> > And I guess it begs the question: Why have *any* controls in the core of
> JavaFX at all?
> >
> > Graciously,
> >
> > John-Val Rose
> > Rosethorn Technology
> >
> >> On 5 Oct 2018, at 23:34, Kevin Rushforth <kevin.rushforth at oracle.com>
> wrote:
> >>
> >> I agree that new controls, especially a RichText control, should very
> likely not be part of the core -- at least not at first. Somewhere like
> ControlsFX might be a great place to develop it. What we need to do is
> identify the missing pieces that prevent it from being implemented as an
> external control. The text measurement API is one such missing piece, but
> I'll bet there are others.
> >>
> >> -- Kevin
> >>
> >>
> >>> On 10/3/2018 11:08 AM, Tom Schindl wrote:
> >>> Hi,
> >>>
> >>> I fully agree and I don't think such a control should be part of the
> >>> OpenJFX but should live in an other library.
> >>>
> >>> /me thinks OpenJFX should not get *ANY* new controls (I would even
> argue
> >>> that the current controls should be split out) but provide the core
> APIs
> >>> needed to implement them.
> >>>
> >>> Tom
> >>>
> >>>> On 03.10.18 19:39, Phil Race wrote:
> >>>>
> >>>>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
> >>>>> I think to start, probably a class like Swing's FontMetrics would be
> good
> >>>>> to have? Before Java 9 there was one but it was private
> implementation.
> >>>>> Just to have the basic API that would allow to build rich text
> editing
> >>>>> support more easily, sorted out..
> >>>>> This is also, generally, needed for calculating how to lay out text.
> >>>> I agree, and maybe I should aim to finally implement this in 12 :
> >>>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
> >>>> measurement API
> >>>>
> >>>> -phil.
>
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From johnvalrose at gmail.com  Fri Oct  5 20:58:48 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sat, 6 Oct 2018 06:58:48 +1000
Subject: Rich Text Support
In-Reply-To: <CAAEud6bbNLqotLVW6D2n6RA2q3MeLZGdXVKbNXe1aNkrFFUZwg@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <63E5831F-FDE6-4EE5-A2D7-3F590B500D0F@gmail.com>
 <CAAEud6bvXWsxDCq45R3e4NBd20OGDtntTbZ6wVWxCHexKsj6uA@mail.gmail.com>
 <a2e4886a-a882-4ef9-a72d-7259444b1842@oracle.com>
 <a5177bd6-d90b-2796-a7bd-99b938447f6f@bestsolution.at>
 <98fd8677-8ed1-d98a-11bf-d16946c0c7d0@oracle.com>
 <9F7C6B25-F64D-4D47-A22C-911C8145E7C4@gmail.com>
 <fa1daaeb-632f-1d37-642e-dc7efeb803b9@oracle.com>
 <CAAEud6bbNLqotLVW6D2n6RA2q3MeLZGdXVKbNXe1aNkrFFUZwg@mail.gmail.com>
Message-ID: <B682B14B-4C29-4FCE-9A84-4DA71A0179E3@gmail.com>

OK, thanks Kevin and everyone else who provided reasoning to answer my question.

As I said, I was ?curious? but the arguments put forward have satisfied that curiosity :-)

I agree that by allowing the JavaFX team to focus on lower level functionality, it is a means of expediting progress to the core library thus enabling others to create many  more controls in 3rd party libraries.

Who knows - maybe we?ll end up with 10 different really good rich text editors if such important core features like font metrics etc. are implemented within JavaFX itself!

> On 6 Oct 2018, at 06:51, Pedro Duque Vieira <pedro.duquevieira at gmail.com> wrote:
> 
> I agree. 
> 
> A UI framework needs at least a standard set of controls in its core. I'd say at least 90% of UI apps being created need at least a couple of UI controls.
> 
> I think we should focus on having a strong core library that would allow to build additional controls, by at least third parties. Things like FontMetrics like API are strongly needed, not just for Rich Text editor and not just for UI controls and should be the priority. Other things that can be built outside the openjfx, like a rich text editor, are nice to have but not a priority.
> 
> I agree that things like rich text editors can be built outside first and then integrated. I believe this is the best workflow has it allows for prototyping,  experimenting,  getting feedback from users and iterating. And when it has a pretty solid API and user experience it can be integrated inside the openjfx library, because then things will get much more complicated to change and break.
> 
> Cheers,
> 
>> On Fri, Oct 5, 2018 at 9:32 PM Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> Note that I did say "at least at first" when I was agreeing that it 
>> should likely not be part of the core. Developing a RichText control is 
>> going to be a big task that will likely take a bit of experimenting to 
>> get everything right. Doing that externally would allow for more rapid 
>> prototyping and testing before committing to a core API. If it becomes 
>> something that is generally considered useful, and fits well with the 
>> other controls, then I don't necessarily see a problem getting it into 
>> the core (although it would need to go through an feature review just 
>> like any new API). That was what we did for Alert and Spinner when they 
>> were first implemented; both needed a fair bit of additional work before 
>> bringing it into javafx.controls, but it was heavily leveraged by the 
>> work done in ControlsFX.
>> 
>> Btw, I might feel the same way about, say, DatePicker if we were 
>> developing it now. However, I do think that almost all of the current 
>> set fit within what I would expect a UI toolkit to provide as a default 
>> set of controls.
>> 
>> Johan might have a somewhat different take on this, so it would be good 
>> to get his thoughts.
>> 
>> -- Kevin
>> 
>> 
>> On 10/5/2018 12:59 PM, John-Val Rose wrote:
>> > Kevin,
>> >
>> > I am somewhat curious as to this idea that new JavaFX controls should not be part of the core toolkit.
>> >
>> > Why do feel this way?
>> >
>> > And I guess it begs the question: Why have *any* controls in the core of JavaFX at all?
>> >
>> > Graciously,
>> >
>> > John-Val Rose
>> > Rosethorn Technology
>> >
>> >> On 5 Oct 2018, at 23:34, Kevin Rushforth <kevin.rushforth at oracle.com> wrote:
>> >>
>> >> I agree that new controls, especially a RichText control, should very likely not be part of the core -- at least not at first. Somewhere like ControlsFX might be a great place to develop it. What we need to do is identify the missing pieces that prevent it from being implemented as an external control. The text measurement API is one such missing piece, but I'll bet there are others.
>> >>
>> >> -- Kevin
>> >>
>> >>
>> >>> On 10/3/2018 11:08 AM, Tom Schindl wrote:
>> >>> Hi,
>> >>>
>> >>> I fully agree and I don't think such a control should be part of the
>> >>> OpenJFX but should live in an other library.
>> >>>
>> >>> /me thinks OpenJFX should not get *ANY* new controls (I would even argue
>> >>> that the current controls should be split out) but provide the core APIs
>> >>> needed to implement them.
>> >>>
>> >>> Tom
>> >>>
>> >>>> On 03.10.18 19:39, Phil Race wrote:
>> >>>>
>> >>>>> On 10/03/2018 05:50 AM, Pedro Duque Vieira wrote:
>> >>>>> I think to start, probably a class like Swing's FontMetrics would be good
>> >>>>> to have? Before Java 9 there was one but it was private implementation.
>> >>>>> Just to have the basic API that would allow to build rich text editing
>> >>>>> support more easily, sorted out..
>> >>>>> This is also, generally, needed for calculating how to lay out text.
>> >>>> I agree, and maybe I should aim to finally implement this in 12 :
>> >>>> https://bugs.openjdk.java.net/browse/JDK-8090775: Need font/text
>> >>>> measurement API
>> >>>>
>> >>>> -phil.
>> 
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com

From chengen.zhao at whitewoodcity.com  Sat Oct  6 12:59:14 2018
From: chengen.zhao at whitewoodcity.com (Chengen Zhao)
Date: Sat, 06 Oct 2018 20:59:14 +0800
Subject: =?UTF-8?B?VnVsa2FuLCBNZW50YWwgYW5kIGN1c3RvbWl6ZWQgTm9kZSBTdXBwb3J0PyBhbmQgc3RhYmxl?=
 =?UTF-8?B?IHByaXNtIGFwaQ==?=
Message-ID: <512b1f23-a0dd-4adf-87ca-2ce58179ee2f.chengen.zhao@whitewoodcity.com>

Hi:

We are currently using JavaFX to create games on Steam
and it works pretty good on 2D games
and we do have some concerns
1) OpenGL seems like is deprecating on MacOSX and Fuchsia which only supports Vulkan based on their Github repo
and I think OpenJDK will be inevitably ported to Fuchsia and Vulkan seems like is OpenGL next generation(5)
so is there any schedule or roadmap for Vulkan and Mental supports?
2) I have read several discussions about prism and we are considering using lwjgl to create 3d node
but prism is not that stable and is not documented which means the prism api may be changed in future
and there is no guarantees for that so is it possible to create a uniform and relatively stable interfaces/api for prism?
thus it could be easier for 3rd parties to implement their own graphics api support 
and in that case, lwjgl could create 3DNode in JavaFX node hierachy which is expected by many developers:)
3) similar to 2, if the interface of Node could be more documented and stable, 
then it would be easier for other developers to create their own Node
this could be related to RichTextNode

Cheers

From tom.schindl at bestsolution.at  Sat Oct  6 17:04:35 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sat, 6 Oct 2018 19:04:35 +0200
Subject: Vulkan, Mental and customized Node Support? and stable prism api
In-Reply-To: <512b1f23-a0dd-4adf-87ca-2ce58179ee2f.chengen.zhao@whitewoodcity.com>
References: <512b1f23-a0dd-4adf-87ca-2ce58179ee2f.chengen.zhao@whitewoodcity.com>
Message-ID: <35E6043D-78EE-471D-9E92-5C7E27F7F120@bestsolution.at>

Hi,

We - BestSolution together with some of our customers - are currently doing a PoC to integrate native rendering (OpenGL and D3D) into OpenJFX.

So far our progress is very good and we hope we can share something very soon.

Tom

Von meinem iPhone gesendet

> Am 06.10.2018 um 14:59 schrieb Chengen Zhao <chengen.zhao at whitewoodcity.com>:
> 
> Hi:
> 
> We are currently using JavaFX to create games on Steam
> and it works pretty good on 2D games
> and we do have some concerns
> 1) OpenGL seems like is deprecating on MacOSX and Fuchsia which only supports Vulkan based on their Github repo
> and I think OpenJDK will be inevitably ported to Fuchsia and Vulkan seems like is OpenGL next generation(5)
> so is there any schedule or roadmap for Vulkan and Mental supports?
> 2) I have read several discussions about prism and we are considering using lwjgl to create 3d node
> but prism is not that stable and is not documented which means the prism api may be changed in future
> and there is no guarantees for that so is it possible to create a uniform and relatively stable interfaces/api for prism?
> thus it could be easier for 3rd parties to implement their own graphics api support 
> and in that case, lwjgl could create 3DNode in JavaFX node hierachy which is expected by many developers:)
> 3) similar to 2, if the interface of Node could be more documented and stable, 
> then it would be easier for other developers to create their own Node
> this could be related to RichTextNode
> 
> Cheers


From pedro.duquevieira at gmail.com  Mon Oct  8 16:28:50 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 8 Oct 2018 17:28:50 +0100
Subject: Rich Text Support
In-Reply-To: <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
Message-ID: <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>

I'm not sure, but I think Robert might have only replied to me (probably by
mistake) and not the whole openjfx list as well. It has happened to me
before :)
He makes some points that are probably of interest to this discussion. If
his email didn't get to the openjfx mailing list, it is below.

I'd like to make some comments to the points he raised:

When I mentioned TextFlow I was mentioning it for the rich text display
part only. As I mentioned, for the editing, I think it would be good to
have more API in the JavaFX SDK to facilitate developing a Rich text
editor. Like I said, FontMetrics would be a nice addition, not just for
rich text editing but for anything that involves laying out text and other
things. So this would be very good to have. Right now you have to resort to
hacks when laying out text, and for some things you simply don't have the
API.
Other good additions to the API, which are also relevant to this
discussion, would be to be able to know which character has been clicked on
in a text node, either via mouse or touch. FontMetrics could also help with
this.

When creating a Rich Text editor with a scene graph approach and retained
mode (vs using an approach like using Canvas), we'd have to use a technic
that doesn't use a Node for every character or word. Otherwise we will
eventually have thousands of nodes in the scene which will kill performance
and memory. One of those techniques is to use virtualization, via the use
of a ListView for example. Each cell can be a TextFlow representing a line
that would automatically be re-used by the ListView. So I don't think we
must resort to using Canvas. Personally I prefer using a scene graph based
approach.

Like I said, I've never actually implemented or tried to implement a rich
text editor, so there might be people with better knowledge and experience
in this list to talk about this.
My 2 cents.








On Mon, Oct 8, 2018 at 3:05 PM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira:
> > Hi,
> >
> > Have you guys tried JavaFX TextFlow class and such for just the display
> > part of rich text?
>
> I have some (albeit very old now) background in writing an editor for an
> IDE.
>
> The the best of my knowledge, TextFlow is not even usable to display
> large amounts of (colored/highlighted) text let alone make it editable.
>
> I've tried and rigged together a little piece of code that would display
> an XML file in a colorful way (i.e. three to five Texts per line plus an
> additional Text-Object per line).
>
> Displaying a file with 5 MB will consume a whopping 800 MB of
> Text-objects in that way. The application has never been able to render
> anything beyond tiny files.
>
> Displaying text files in a graph of nodes is just plain wrong. You have
> to invert the situation so that only the part of the file that is
> currently visible gets rendered.
> That is where things get complicated (in my opinion), because JavaFX
> dictates (AFAIK) that rendering has to be the other way round. While
> painting callbacks may seem like an artifact of the past they are
> superior when it comes to rendering texts. (Model-View-Controller ...
> anyone still remembering ?)
>
> Maybe something can be done with a Canvas in a ScrollPane (will have to
> try that), but TextFlow seems to rather mislead people into the wrong
> direction.
>
> BTW, TextArea is also very bad performance-wise: Loading the 5 MB file
> into a textarea makes the application unresponsive (on both Linux and
> Windows)
>
> Robert Lichtenberger
>
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From tom.schindl at bestsolution.at  Mon Oct  8 17:54:30 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Mon, 8 Oct 2018 19:54:30 +0200
Subject: Rich Text Support
In-Reply-To: <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
Message-ID: <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>

Hi,

as someone who has written a Code-Editor-Control (I don't talk about
RichText) I can say that what Robert says is wrong and other examples
like all Web-Based code editors (Monaco, Orion) show us it is perfectly
possible implement well performing Code editor using a Scene-Graph.

The trick is as always you need to be virtual (ideally in both
directions but as a minimum vertically). For code-editors an
optimization you can use is that often you have monospaced fonts so you
can very easily interpolate stuff.

Some more comments inline

On 08.10.18 18:28, Pedro Duque Vieira wrote:
> I'm not sure, but I think Robert might have only replied to me (probably by
> mistake) and not the whole openjfx list as well. It has happened to me
> before :)
> He makes some points that are probably of interest to this discussion. If
> his email didn't get to the openjfx mailing list, it is below.
> 
> I'd like to make some comments to the points he raised:
> 
> When I mentioned TextFlow I was mentioning it for the rich text display
> part only. As I mentioned, for the editing, I think it would be good to
> have more API in the JavaFX SDK to facilitate developing a Rich text
> editor. Like I said, FontMetrics would be a nice addition, not just for
> rich text editing but for anything that involves laying out text and other
> things. So this would be very good to have. Right now you have to resort to
> hacks when laying out text, and for some things you simply don't have the
> API.
> Other good additions to the API, which are also relevant to this
> discussion, would be to be able to know which character has been clicked on
> in a text node, either via mouse or touch. FontMetrics could also help with
> this.

Text-Node has hit-testing so you get the character position as public API.

> 
> When creating a Rich Text editor with a scene graph approach and retained
> mode (vs using an approach like using Canvas), we'd have to use a technic
> that doesn't use a Node for every character or word. Otherwise we will

This is correct. We are currently working on new version of our
Code-Editor control and there we render 1 line with at most 4 Nodes (no
matter how many colored sections you have) in case we have a mono-spaced
font (something we simply defined as a pre-requisit for the moment)

> eventually have thousands of nodes in the scene which will kill performance
> and memory. One of those techniques is to use virtualization, via the use
> of a ListView for example. Each cell can be a TextFlow representing a line
> that would automatically be re-used by the ListView. So I don't think we
> must resort to using Canvas. Personally I prefer using a scene graph based
> approach.

As I said above ListView like support at minimum but ideally you are
virtual in both directions - something our rebuild code-editor control
is going to support.

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From johnvalrose at gmail.com  Mon Oct  8 18:46:14 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 9 Oct 2018 05:46:14 +1100
Subject: Rich Text Support
In-Reply-To: <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
 <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
Message-ID: <E104AB51-F402-45EF-81E0-94DE50BF61FF@gmail.com>

Tom,

I think I must have missed a part of this thread.

Who is Robert? And which post are you extracting those quoted passages from to which you respond?

I look forward to your rebuilt editor BTW :-)

> On 9 Oct 2018, at 04:54, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Hi,
> 
> as someone who has written a Code-Editor-Control (I don't talk about
> RichText) I can say that what Robert says is wrong and other examples
> like all Web-Based code editors (Monaco, Orion) show us it is perfectly
> possible implement well performing Code editor using a Scene-Graph.
> 
> The trick is as always you need to be virtual (ideally in both
> directions but as a minimum vertically). For code-editors an
> optimization you can use is that often you have monospaced fonts so you
> can very easily interpolate stuff.
> 
> Some more comments inline
> 
>> On 08.10.18 18:28, Pedro Duque Vieira wrote:
>> I'm not sure, but I think Robert might have only replied to me (probably by
>> mistake) and not the whole openjfx list as well. It has happened to me
>> before :)
>> He makes some points that are probably of interest to this discussion. If
>> his email didn't get to the openjfx mailing list, it is below.
>> 
>> I'd like to make some comments to the points he raised:
>> 
>> When I mentioned TextFlow I was mentioning it for the rich text display
>> part only. As I mentioned, for the editing, I think it would be good to
>> have more API in the JavaFX SDK to facilitate developing a Rich text
>> editor. Like I said, FontMetrics would be a nice addition, not just for
>> rich text editing but for anything that involves laying out text and other
>> things. So this would be very good to have. Right now you have to resort to
>> hacks when laying out text, and for some things you simply don't have the
>> API.
>> Other good additions to the API, which are also relevant to this
>> discussion, would be to be able to know which character has been clicked on
>> in a text node, either via mouse or touch. FontMetrics could also help with
>> this.
> 
> Text-Node has hit-testing so you get the character position as public API.
> 
>> 
>> When creating a Rich Text editor with a scene graph approach and retained
>> mode (vs using an approach like using Canvas), we'd have to use a technic
>> that doesn't use a Node for every character or word. Otherwise we will
> 
> This is correct. We are currently working on new version of our
> Code-Editor control and there we render 1 line with at most 4 Nodes (no
> matter how many colored sections you have) in case we have a mono-spaced
> font (something we simply defined as a pre-requisit for the moment)
> 
>> eventually have thousands of nodes in the scene which will kill performance
>> and memory. One of those techniques is to use virtualization, via the use
>> of a ListView for example. Each cell can be a TextFlow representing a line
>> that would automatically be re-used by the ListView. So I don't think we
>> must resort to using Canvas. Personally I prefer using a scene graph based
>> approach.
> 
> As I said above ListView like support at minimum but ideally you are
> virtual in both directions - something our rebuild code-editor control
> is going to support.
> 
> Tom
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From pedro.duquevieira at gmail.com  Mon Oct  8 18:53:24 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 8 Oct 2018 19:53:24 +0100
Subject: Rich Text Support
In-Reply-To: <E104AB51-F402-45EF-81E0-94DE50BF61FF@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
 <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
 <E104AB51-F402-45EF-81E0-94DE50BF61FF@gmail.com>
Message-ID: <CAAEud6Zv48YBLSdFVYmqsaFd33EEvRZ9SRH32hdQZYxCQd03BA@mail.gmail.com>

Robert answered directly to me instead of to the whole openjfx thread (a
mistake that sometimes happens). I replied earlier to the group with his
email quoted below.

This mailing list stuff is sometimes a bit confusing.. I find forums and
google groups a bit more user friendly :)

I hope that clarifies it. Cheers,



On Mon, Oct 8, 2018 at 7:46 PM John-Val Rose <johnvalrose at gmail.com> wrote:

> Tom,
>
> I think I must have missed a part of this thread.
>
> Who is Robert? And which post are you extracting those quoted passages
> from to which you respond?
>
> I look forward to your rebuilt editor BTW :-)
>
> > On 9 Oct 2018, at 04:54, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
> >
> > Hi,
> >
> > as someone who has written a Code-Editor-Control (I don't talk about
> > RichText) I can say that what Robert says is wrong and other examples
> > like all Web-Based code editors (Monaco, Orion) show us it is perfectly
> > possible implement well performing Code editor using a Scene-Graph.
> >
> > The trick is as always you need to be virtual (ideally in both
> > directions but as a minimum vertically). For code-editors an
> > optimization you can use is that often you have monospaced fonts so you
> > can very easily interpolate stuff.
> >
> > Some more comments inline
> >
> >> On 08.10.18 18:28, Pedro Duque Vieira wrote:
> >> I'm not sure, but I think Robert might have only replied to me
> (probably by
> >> mistake) and not the whole openjfx list as well. It has happened to me
> >> before :)
> >> He makes some points that are probably of interest to this discussion.
> If
> >> his email didn't get to the openjfx mailing list, it is below.
> >>
> >> I'd like to make some comments to the points he raised:
> >>
> >> When I mentioned TextFlow I was mentioning it for the rich text display
> >> part only. As I mentioned, for the editing, I think it would be good to
> >> have more API in the JavaFX SDK to facilitate developing a Rich text
> >> editor. Like I said, FontMetrics would be a nice addition, not just for
> >> rich text editing but for anything that involves laying out text and
> other
> >> things. So this would be very good to have. Right now you have to
> resort to
> >> hacks when laying out text, and for some things you simply don't have
> the
> >> API.
> >> Other good additions to the API, which are also relevant to this
> >> discussion, would be to be able to know which character has been
> clicked on
> >> in a text node, either via mouse or touch. FontMetrics could also help
> with
> >> this.
> >
> > Text-Node has hit-testing so you get the character position as public
> API.
> >
> >>
> >> When creating a Rich Text editor with a scene graph approach and
> retained
> >> mode (vs using an approach like using Canvas), we'd have to use a
> technic
> >> that doesn't use a Node for every character or word. Otherwise we will
> >
> > This is correct. We are currently working on new version of our
> > Code-Editor control and there we render 1 line with at most 4 Nodes (no
> > matter how many colored sections you have) in case we have a mono-spaced
> > font (something we simply defined as a pre-requisit for the moment)
> >
> >> eventually have thousands of nodes in the scene which will kill
> performance
> >> and memory. One of those techniques is to use virtualization, via the
> use
> >> of a ListView for example. Each cell can be a TextFlow representing a
> line
> >> that would automatically be re-used by the ListView. So I don't think we
> >> must resort to using Canvas. Personally I prefer using a scene graph
> based
> >> approach.
> >
> > As I said above ListView like support at minimum but ideally you are
> > virtual in both directions - something our rebuild code-editor control
> > is going to support.
> >
> > Tom
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From johnvalrose at gmail.com  Mon Oct  8 18:56:35 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 9 Oct 2018 05:56:35 +1100
Subject: Rich Text Support
In-Reply-To: <CAAEud6Zv48YBLSdFVYmqsaFd33EEvRZ9SRH32hdQZYxCQd03BA@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
 <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
 <E104AB51-F402-45EF-81E0-94DE50BF61FF@gmail.com>
 <CAAEud6Zv48YBLSdFVYmqsaFd33EEvRZ9SRH32hdQZYxCQd03BA@mail.gmail.com>
Message-ID: <F74A8A8E-8E4B-47FE-8355-31878A570255@gmail.com>

Thanks Pedro for the explanation. Very helpful.

I was concerned that maybe only some posts to this list end up in my inbox but you?ve cleared that up for me now :-)

> On 9 Oct 2018, at 05:53, Pedro Duque Vieira <pedro.duquevieira at gmail.com> wrote:
> 
> Robert answered directly to me instead of to the whole openjfx thread (a mistake that sometimes happens). I replied earlier to the group with his email quoted below.
> 
> This mailing list stuff is sometimes a bit confusing.. I find forums and google groups a bit more user friendly :)
> 
> I hope that clarifies it. Cheers,
> 
> 
> 
>> On Mon, Oct 8, 2018 at 7:46 PM John-Val Rose <johnvalrose at gmail.com> wrote:
>> Tom,
>> 
>> I think I must have missed a part of this thread.
>> 
>> Who is Robert? And which post are you extracting those quoted passages from to which you respond?
>> 
>> I look forward to your rebuilt editor BTW :-)
>> 
>> > On 9 Oct 2018, at 04:54, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>> > 
>> > Hi,
>> > 
>> > as someone who has written a Code-Editor-Control (I don't talk about
>> > RichText) I can say that what Robert says is wrong and other examples
>> > like all Web-Based code editors (Monaco, Orion) show us it is perfectly
>> > possible implement well performing Code editor using a Scene-Graph.
>> > 
>> > The trick is as always you need to be virtual (ideally in both
>> > directions but as a minimum vertically). For code-editors an
>> > optimization you can use is that often you have monospaced fonts so you
>> > can very easily interpolate stuff.
>> > 
>> > Some more comments inline
>> > 
>> >> On 08.10.18 18:28, Pedro Duque Vieira wrote:
>> >> I'm not sure, but I think Robert might have only replied to me (probably by
>> >> mistake) and not the whole openjfx list as well. It has happened to me
>> >> before :)
>> >> He makes some points that are probably of interest to this discussion. If
>> >> his email didn't get to the openjfx mailing list, it is below.
>> >> 
>> >> I'd like to make some comments to the points he raised:
>> >> 
>> >> When I mentioned TextFlow I was mentioning it for the rich text display
>> >> part only. As I mentioned, for the editing, I think it would be good to
>> >> have more API in the JavaFX SDK to facilitate developing a Rich text
>> >> editor. Like I said, FontMetrics would be a nice addition, not just for
>> >> rich text editing but for anything that involves laying out text and other
>> >> things. So this would be very good to have. Right now you have to resort to
>> >> hacks when laying out text, and for some things you simply don't have the
>> >> API.
>> >> Other good additions to the API, which are also relevant to this
>> >> discussion, would be to be able to know which character has been clicked on
>> >> in a text node, either via mouse or touch. FontMetrics could also help with
>> >> this.
>> > 
>> > Text-Node has hit-testing so you get the character position as public API.
>> > 
>> >> 
>> >> When creating a Rich Text editor with a scene graph approach and retained
>> >> mode (vs using an approach like using Canvas), we'd have to use a technic
>> >> that doesn't use a Node for every character or word. Otherwise we will
>> > 
>> > This is correct. We are currently working on new version of our
>> > Code-Editor control and there we render 1 line with at most 4 Nodes (no
>> > matter how many colored sections you have) in case we have a mono-spaced
>> > font (something we simply defined as a pre-requisit for the moment)
>> > 
>> >> eventually have thousands of nodes in the scene which will kill performance
>> >> and memory. One of those techniques is to use virtualization, via the use
>> >> of a ListView for example. Each cell can be a TextFlow representing a line
>> >> that would automatically be re-used by the ListView. So I don't think we
>> >> must resort to using Canvas. Personally I prefer using a scene graph based
>> >> approach.
>> > 
>> > As I said above ListView like support at minimum but ideally you are
>> > virtual in both directions - something our rebuild code-editor control
>> > is going to support.
>> > 
>> > Tom
>> > 
>> > -- 
>> > Tom Schindl, CTO
>> > BestSolution.at EDV Systemhaus GmbH
>> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com

From johnvalrose at gmail.com  Mon Oct  8 20:05:15 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 9 Oct 2018 07:05:15 +1100
Subject: Rich Text Support
In-Reply-To: <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
Message-ID: <6803F318-CC2F-40D2-AD6D-F888F4D22CCB@gmail.com>

Thanks for sharing that - it?s really helpful.

And we all make mistakes. It?s what makes us ?human? (As I?m sure Commander Data would agree).

> On 9 Oct 2018, at 03:28, Pedro Duque Vieira <pedro.duquevieira at gmail.com> wrote:
> 
> I'm not sure, but I think Robert might have only replied to me (probably by
> mistake) and not the whole openjfx list as well. It has happened to me
> before :)
> He makes some points that are probably of interest to this discussion. If
> his email didn't get to the openjfx mailing list, it is below.
> 
> I'd like to make some comments to the points he raised:
> 
> When I mentioned TextFlow I was mentioning it for the rich text display
> part only. As I mentioned, for the editing, I think it would be good to
> have more API in the JavaFX SDK to facilitate developing a Rich text
> editor. Like I said, FontMetrics would be a nice addition, not just for
> rich text editing but for anything that involves laying out text and other
> things. So this would be very good to have. Right now you have to resort to
> hacks when laying out text, and for some things you simply don't have the
> API.
> Other good additions to the API, which are also relevant to this
> discussion, would be to be able to know which character has been clicked on
> in a text node, either via mouse or touch. FontMetrics could also help with
> this.
> 
> When creating a Rich Text editor with a scene graph approach and retained
> mode (vs using an approach like using Canvas), we'd have to use a technic
> that doesn't use a Node for every character or word. Otherwise we will
> eventually have thousands of nodes in the scene which will kill performance
> and memory. One of those techniques is to use virtualization, via the use
> of a ListView for example. Each cell can be a TextFlow representing a line
> that would automatically be re-used by the ListView. So I don't think we
> must resort to using Canvas. Personally I prefer using a scene graph based
> approach.
> 
> Like I said, I've never actually implemented or tried to implement a rich
> text editor, so there might be people with better knowledge and experience
> in this list to talk about this.
> My 2 cents.
> 
> 
> 
> 
> 
> 
> 
> 
> On Mon, Oct 8, 2018 at 3:05 PM Robert Lichtenberger <
> r.lichtenberger at gmail.com> wrote:
> 
>>> Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira:
>>> Hi,
>>> 
>>> Have you guys tried JavaFX TextFlow class and such for just the display
>>> part of rich text?
>> 
>> I have some (albeit very old now) background in writing an editor for an
>> IDE.
>> 
>> The the best of my knowledge, TextFlow is not even usable to display
>> large amounts of (colored/highlighted) text let alone make it editable.
>> 
>> I've tried and rigged together a little piece of code that would display
>> an XML file in a colorful way (i.e. three to five Texts per line plus an
>> additional Text-Object per line).
>> 
>> Displaying a file with 5 MB will consume a whopping 800 MB of
>> Text-objects in that way. The application has never been able to render
>> anything beyond tiny files.
>> 
>> Displaying text files in a graph of nodes is just plain wrong. You have
>> to invert the situation so that only the part of the file that is
>> currently visible gets rendered.
>> That is where things get complicated (in my opinion), because JavaFX
>> dictates (AFAIK) that rendering has to be the other way round. While
>> painting callbacks may seem like an artifact of the past they are
>> superior when it comes to rendering texts. (Model-View-Controller ...
>> anyone still remembering ?)
>> 
>> Maybe something can be done with a Canvas in a ScrollPane (will have to
>> try that), but TextFlow seems to rather mislead people into the wrong
>> direction.
>> 
>> BTW, TextArea is also very bad performance-wise: Loading the 5 MB file
>> into a textarea makes the application unresponsive (on both Linux and
>> Windows)
>> 
>> Robert Lichtenberger
>> 
>> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com

From r.lichtenberger at gmail.com  Tue Oct  9 05:12:21 2018
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 9 Oct 2018 07:12:21 +0200
Subject: Rich Text Support
In-Reply-To: <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
Message-ID: <beded710-7a54-f0fe-2b47-efa99be874c1@gmail.com>

Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira:
> Hi,
>
> Have you guys tried JavaFX TextFlow class and such for just the display
> part of rich text?
I have some (albeit very old now) background in writing an editor for an
IDE.

The the best of my knowledge, TextFlow is not even usable to display
large amounts of (colored/highlighted) text let alone make it editable.

I've tried and rigged together a little piece of code that would display
an XML file in a colorful way (i.e. three to five Texts per line plus an
additional Text-Object per line).

Displaying a file with 5 MB will consume a whopping 800 MB of
Text-objects in that way. The application has never been able to render
anything beyond tiny files.

Displaying text files in a graph of nodes is just plain wrong. You have
to invert the situation so that only the part of the file that is
currently visible gets rendered.
That is where things get complicated (in my opinion), because JavaFX
dictates (AFAIK) that rendering has to be the other way round. While
painting callbacks may seem like an artifact of the past they are
superior when it comes to rendering texts. (Model-View-Controller ...
anyone still remembering ?)

Maybe something can be done with a Canvas in a ScrollPane (will have to
try that), but TextFlow seems to rather mislead people into the wrong
direction.

BTW, TextArea is also very bad performance-wise: Loading the 5 MB file
into a textarea makes the application unresponsive (on both Linux and
Windows)




From johnvalrose at gmail.com  Tue Oct  9 05:20:04 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 9 Oct 2018 16:20:04 +1100
Subject: Rich Text Support
In-Reply-To: <beded710-7a54-f0fe-2b47-efa99be874c1@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <beded710-7a54-f0fe-2b47-efa99be874c1@gmail.com>
Message-ID: <2271F690-6C80-4C46-B068-80D1C7762432@gmail.com>

Everything you have just stated is exactly what I have personally experienced.

The architecture of JavaFX unfortunately leaves few or no alternatives to these kind of issues.

That?s the main aspect we as the JavaFX need to not only address but also to improve/fix.

> On 9 Oct 2018, at 16:12, Robert Lichtenberger <r.lichtenberger at gmail.com> wrote:
> 
>> Am 03.10.2018 um 14:21 schrieb Pedro Duque Vieira:
>> Hi,
>> 
>> Have you guys tried JavaFX TextFlow class and such for just the display
>> part of rich text?
> I have some (albeit very old now) background in writing an editor for an
> IDE.
> 
> The the best of my knowledge, TextFlow is not even usable to display
> large amounts of (colored/highlighted) text let alone make it editable.
> 
> I've tried and rigged together a little piece of code that would display
> an XML file in a colorful way (i.e. three to five Texts per line plus an
> additional Text-Object per line).
> 
> Displaying a file with 5 MB will consume a whopping 800 MB of
> Text-objects in that way. The application has never been able to render
> anything beyond tiny files.
> 
> Displaying text files in a graph of nodes is just plain wrong. You have
> to invert the situation so that only the part of the file that is
> currently visible gets rendered.
> That is where things get complicated (in my opinion), because JavaFX
> dictates (AFAIK) that rendering has to be the other way round. While
> painting callbacks may seem like an artifact of the past they are
> superior when it comes to rendering texts. (Model-View-Controller ...
> anyone still remembering ?)
> 
> Maybe something can be done with a Canvas in a ScrollPane (will have to
> try that), but TextFlow seems to rather mislead people into the wrong
> direction.
> 
> BTW, TextArea is also very bad performance-wise: Loading the 5 MB file
> into a textarea makes the application unresponsive (on both Linux and
> Windows)
> 
> 
> 

From r.lichtenberger at gmail.com  Tue Oct  9 05:28:59 2018
From: r.lichtenberger at gmail.com (Robert Lichtenberger)
Date: Tue, 9 Oct 2018 07:28:59 +0200
Subject: Rich Text Support
In-Reply-To: <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
 <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
Message-ID: <873c3f49-58d7-8190-f95e-11403dcda4a0@gmail.com>

Am 08.10.2018 um 19:54 schrieb Tom Schindl:
> Hi,
>
> as someone who has written a Code-Editor-Control (I don't talk about
> RichText) I can say that what Robert says is wrong and other examples
> like all Web-Based code editors (Monaco, Orion) show us it is perfectly
> possible implement well performing Code editor using a Scene-Graph.
>
> The trick is as always you need to be virtual (ideally in both
> directions but as a minimum vertically). 
That is the "trick". However the fact that you need such a trick goes to
show that it is _harder_ to implement text editors with a scene graph.
You have to know that it is impossible to have your whole text in the
scene. Whereas the framework as such suggests you should do so.

But I admit it is not impossible.

> For code-editors an
> optimization you can use is that often you have monospaced fonts so you
> can very easily interpolate stuff.
Personally I always (yes, even in the IDE) prefer proportional fonts, as
they use less screen space and are easier to read.
But yes, it gets a whole lot easier when you don't have to calculate
variable line heights.

>
> As I said above ListView like support at minimum but ideally you are
> virtual in both directions - something our rebuild code-editor control
> is going to support.
Having virtualization in both directions will certainly help if you open
that file with X MB all in one line, something that most editors / list
views choke upon.

Thanks for the input (especially about the virtualization part), I'll
try to study this in more detail, maybe I'll be able to resurrect my old
editor code with that.

Robert


From pedro.duquevieira at gmail.com  Tue Oct  9 12:57:21 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 9 Oct 2018 13:57:21 +0100
Subject: Rich Text Support
In-Reply-To: <873c3f49-58d7-8190-f95e-11403dcda4a0@gmail.com>
References: <E644D51E-020C-4422-9691-012E8D420A15@gmail.com>
 <CAAEud6Yg+2r4GYOQCpy+eAMZwqEGy29tmNc7ZTOYkOTOrK8D=A@mail.gmail.com>
 <342a05a8-d911-aeea-353f-dacb98a0560f@gmail.com>
 <CAAEud6ZZFgPZ9NQT2FXJf=2ncDpRpv40=5W0CU=D=h9iH5D7aA@mail.gmail.com>
 <0974f0da-eb9d-f029-ee82-3be705c8b5ea@bestsolution.at>
 <873c3f49-58d7-8190-f95e-11403dcda4a0@gmail.com>
Message-ID: <CAAEud6Yp8RrL6B7k2AxbDrqmmrJ9CD8zQU+DpjG3=AcDAdT0ww@mail.gmail.com>

It appears the hit testing for the Text node was introduced in newer
versions of JavaFX. I wasn't aware of this. Just checked the newer versions
of the API and there it is. That's a nice addition!

As a note, UI virtualization isn't exclusive to JavaFX. Nor an issue only
JavaFX has. You'll see this in android development, windows native
development, etc..

Cheers,





On Tue, Oct 9, 2018 at 6:29 AM Robert Lichtenberger <
r.lichtenberger at gmail.com> wrote:

> Am 08.10.2018 um 19:54 schrieb Tom Schindl:
> > Hi,
> >
> > as someone who has written a Code-Editor-Control (I don't talk about
> > RichText) I can say that what Robert says is wrong and other examples
> > like all Web-Based code editors (Monaco, Orion) show us it is perfectly
> > possible implement well performing Code editor using a Scene-Graph.
> >
> > The trick is as always you need to be virtual (ideally in both
> > directions but as a minimum vertically).
> That is the "trick". However the fact that you need such a trick goes to
> show that it is _harder_ to implement text editors with a scene graph.
> You have to know that it is impossible to have your whole text in the
> scene. Whereas the framework as such suggests you should do so.
>
> But I admit it is not impossible.
>
> > For code-editors an
> > optimization you can use is that often you have monospaced fonts so you
> > can very easily interpolate stuff.
> Personally I always (yes, even in the IDE) prefer proportional fonts, as
> they use less screen space and are easier to read.
> But yes, it gets a whole lot easier when you don't have to calculate
> variable line heights.
>
> >
> > As I said above ListView like support at minimum but ideally you are
> > virtual in both directions - something our rebuild code-editor control
> > is going to support.
> Having virtualization in both directions will certainly help if you open
> that file with X MB all in one line, something that most editors / list
> views choke upon.
>
> Thanks for the input (especially about the virtualization part), I'll
> try to study this in more detail, maybe I'll be able to resurrect my old
> editor code with that.
>
> Robert
>
>

-- 
Pedro Duque Vieira - https://www.pixelduke.com

From andrea.liana at ingliana.com  Thu Oct 11 07:42:43 2018
From: andrea.liana at ingliana.com (Andrea Liana)
Date: Thu, 11 Oct 2018 09:42:43 +0200
Subject: Native macOS and Windows Application
Message-ID: <b348d9e8-9fc4-ab9d-41cc-63066ae2c1e5@ingliana.com>

Hello,

I am asking directions about the best way to do obtain a proper macOS 
native application from a Java 11 project. And also for Windows platform.

My current project is made of a number of modules plus some 
not-modularized jars for JDBC access and I need also to include the 
JavaFX 11 modules.

My problem is that the current macOS support for Java inside a ".app" 
still works with classpaths, not modules.

So i tried a different approach:

- I created a template with Platypus (http://sveinbjorn.org/platypus/)

- I made a little program for research purpose that creates all modules 
jars using the compiler API

- with jlink I created a working command line application with all jars, 
modularized and not

- I modified the Platypus template and inserted? the jlink application 
inside the .app; the Platypus script calls the jlink generated start.sh.

The final result is decent but poses some problems for later updates. 
When I was using the classpath approach I was able to update the jars 
included under .app/Contents/Resources folder when needed; now with 
jlink I can no longer apply this strategy.

I am looking for some advice if there is a better approach to obtain a 
native macOS .app / Windows .exe which let me still replace jars with 
later upgrades without distributing the entire application again.

Thanking in advance,

Andrea Liana


From johnvalrose at gmail.com  Sat Oct 13 02:19:07 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Sat, 13 Oct 2018 13:19:07 +1100
Subject: The case for WebGL support
Message-ID: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>

I know I have mentioned this numerous times but maybe this list is the best
place to discuss this particular (missing) feature.

For our needs, there are so many reasons why we could really benefit from
WebGL support even if, as I've also said before, it were only to enable
Google Maps to work in "full" mode.

What do others think about this?  Am I the only one who feels the need for
WebGL as a *priority* feature?

Yes, I do understand that it's not as simple as just "turning it on" and
does open-up the even larger discussion about JavaFX supporting all the
major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.

So, can we discuss this?  I would really like to get responses from people
who have opinions on the merits of WebGL support and also anyone who has
the skills/knowledge to best suggest a means of getting this feature
implemented.

Graciously,

John-Val Rose
Chief Scientist/Architect
Rosethorn Technology
Australia

From pedro.duquevieira at gmail.com  Sat Oct 13 13:48:03 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 13 Oct 2018 14:48:03 +0100
Subject: The case for WebGL support
In-Reply-To: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
References: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
Message-ID: <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>

Not talking about whether this is a needed feature or not, or whether there
is demand for it, because I don't know. But maybe the webview could be
based on the Chromium project (the engine behind Chrome browser), to cut
corners and development time and to have more features than the current one
has. There many projects based on Chromium (e.g: Electron a cross platform
solution for building apps, etc).

In fact there is a project called JCEF, which renders the Chromium browser
into a Swing application.
Perhaps John you could even already use this in your JavaFX apps.

My 2 cents,

On Sat, Oct 13, 2018 at 3:20 AM John-Val Rose <johnvalrose at gmail.com> wrote:

> I know I have mentioned this numerous times but maybe this list is the best
> place to discuss this particular (missing) feature.
>
> For our needs, there are so many reasons why we could really benefit from
> WebGL support even if, as I've also said before, it were only to enable
> Google Maps to work in "full" mode.
>
> What do others think about this?  Am I the only one who feels the need for
> WebGL as a *priority* feature?
>
> Yes, I do understand that it's not as simple as just "turning it on" and
> does open-up the even larger discussion about JavaFX supporting all the
> major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.
>
> So, can we discuss this?  I would really like to get responses from people
> who have opinions on the merits of WebGL support and also anyone who has
> the skills/knowledge to best suggest a means of getting this feature
> implemented.
>
> Graciously,
>
> John-Val Rose
> Chief Scientist/Architect
> Rosethorn Technology
> Australia
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From tom.schindl at bestsolution.at  Sat Oct 13 15:01:00 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Sat, 13 Oct 2018 17:01:00 +0200
Subject: The case for WebGL support
In-Reply-To: <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>
References: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
 <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>
Message-ID: <94A8EFE9-F692-4F6E-AF22-EA47BFFFA56B@bestsolution.at>

Hi,

I think Pedro is right rather than investing into WebGL for WebView I?d invest in using CEF. I think CEF can render offscreen and you can get that Texture ID.

The missing piece then is that we need a way to map native textures into FX - if only someone would work on that :-)

Tom

Von meinem iPhone gesendet

> Am 13.10.2018 um 15:48 schrieb Pedro Duque Vieira <pedro.duquevieira at gmail.com>:
> 
> Not talking about whether this is a needed feature or not, or whether there
> is demand for it, because I don't know. But maybe the webview could be
> based on the Chromium project (the engine behind Chrome browser), to cut
> corners and development time and to have more features than the current one
> has. There many projects based on Chromium (e.g: Electron a cross platform
> solution for building apps, etc).
> 
> In fact there is a project called JCEF, which renders the Chromium browser
> into a Swing application.
> Perhaps John you could even already use this in your JavaFX apps.
> 
> My 2 cents,
> 
>> On Sat, Oct 13, 2018 at 3:20 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>> 
>> I know I have mentioned this numerous times but maybe this list is the best
>> place to discuss this particular (missing) feature.
>> 
>> For our needs, there are so many reasons why we could really benefit from
>> WebGL support even if, as I've also said before, it were only to enable
>> Google Maps to work in "full" mode.
>> 
>> What do others think about this?  Am I the only one who feels the need for
>> WebGL as a *priority* feature?
>> 
>> Yes, I do understand that it's not as simple as just "turning it on" and
>> does open-up the even larger discussion about JavaFX supporting all the
>> major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.
>> 
>> So, can we discuss this?  I would really like to get responses from people
>> who have opinions on the merits of WebGL support and also anyone who has
>> the skills/knowledge to best suggest a means of getting this feature
>> implemented.
>> 
>> Graciously,
>> 
>> John-Val Rose
>> Chief Scientist/Architect
>> Rosethorn Technology
>> Australia
>> 
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com


From johnvalrose at gmail.com  Mon Oct 15 16:05:31 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 16 Oct 2018 03:05:31 +1100
Subject: The case for WebGL support
In-Reply-To: <94A8EFE9-F692-4F6E-AF22-EA47BFFFA56B@bestsolution.at>
References: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
 <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>
 <94A8EFE9-F692-4F6E-AF22-EA47BFFFA56B@bestsolution.at>
Message-ID: <72BD1C43-068E-42A8-A278-237FF4C8A489@gmail.com>

Hi Pedro,

I?m actually using the commercial product known as JxBrowser (for our first commercial JavaFX based product) which is basically a Java wrapper around Chromium and works amazingly well.

But it?s not portable to either iOS or Android which is a ?headache? to say the least.

Graciously,

John-Val

> On 14 Oct 2018, at 02:01, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Hi,
> 
> I think Pedro is right rather than investing into WebGL for WebView I?d invest in using CEF. I think CEF can render offscreen and you can get that Texture ID.
> 
> The missing piece then is that we need a way to map native textures into FX - if only someone would work on that :-)
> 
> Tom
> 
> Von meinem iPhone gesendet
> 
>> Am 13.10.2018 um 15:48 schrieb Pedro Duque Vieira <pedro.duquevieira at gmail.com>:
>> 
>> Not talking about whether this is a needed feature or not, or whether there
>> is demand for it, because I don't know. But maybe the webview could be
>> based on the Chromium project (the engine behind Chrome browser), to cut
>> corners and development time and to have more features than the current one
>> has. There many projects based on Chromium (e.g: Electron a cross platform
>> solution for building apps, etc).
>> 
>> In fact there is a project called JCEF, which renders the Chromium browser
>> into a Swing application.
>> Perhaps John you could even already use this in your JavaFX apps.
>> 
>> My 2 cents,
>> 
>>> On Sat, Oct 13, 2018 at 3:20 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>>> 
>>> I know I have mentioned this numerous times but maybe this list is the best
>>> place to discuss this particular (missing) feature.
>>> 
>>> For our needs, there are so many reasons why we could really benefit from
>>> WebGL support even if, as I've also said before, it were only to enable
>>> Google Maps to work in "full" mode.
>>> 
>>> What do others think about this?  Am I the only one who feels the need for
>>> WebGL as a *priority* feature?
>>> 
>>> Yes, I do understand that it's not as simple as just "turning it on" and
>>> does open-up the even larger discussion about JavaFX supporting all the
>>> major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.
>>> 
>>> So, can we discuss this?  I would really like to get responses from people
>>> who have opinions on the merits of WebGL support and also anyone who has
>>> the skills/knowledge to best suggest a means of getting this feature
>>> implemented.
>>> 
>>> Graciously,
>>> 
>>> John-Val Rose
>>> Chief Scientist/Architect
>>> Rosethorn Technology
>>> Australia
>>> 
>> 
>> 
>> -- 
>> Pedro Duque Vieira - https://www.pixelduke.com
> 

From pedro.duquevieira at gmail.com  Mon Oct 15 16:08:05 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Mon, 15 Oct 2018 17:08:05 +0100
Subject: The case for WebGL support
In-Reply-To: <72BD1C43-068E-42A8-A278-237FF4C8A489@gmail.com>
References: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
 <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>
 <94A8EFE9-F692-4F6E-AF22-EA47BFFFA56B@bestsolution.at>
 <72BD1C43-068E-42A8-A278-237FF4C8A489@gmail.com>
Message-ID: <CAAEud6bmg3644LdHTTQAa4XmkAHEBwXskJzF8Ntj5C6sA=xUUg@mail.gmail.com>

Hi John, and others,

Chromium runs on ios and android so probably, technically, it should be
possible to have it run in the future through JavaFX too.

Cheers,

On Mon, Oct 15, 2018 at 5:05 PM John-Val Rose <johnvalrose at gmail.com> wrote:

> Hi Pedro,
>
> I?m actually using the commercial product known as JxBrowser (for our
> first commercial JavaFX based product) which is basically a Java wrapper
> around Chromium and works amazingly well.
>
> But it?s not portable to either iOS or Android which is a ?headache? to
> say the least.
>
> Graciously,
>
> John-Val
>
> > On 14 Oct 2018, at 02:01, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
> >
> > Hi,
> >
> > I think Pedro is right rather than investing into WebGL for WebView I?d
> invest in using CEF. I think CEF can render offscreen and you can get that
> Texture ID.
> >
> > The missing piece then is that we need a way to map native textures into
> FX - if only someone would work on that :-)
> >
> > Tom
> >
> > Von meinem iPhone gesendet
> >
> >> Am 13.10.2018 um 15:48 schrieb Pedro Duque Vieira <
> pedro.duquevieira at gmail.com>:
> >>
> >> Not talking about whether this is a needed feature or not, or whether
> there
> >> is demand for it, because I don't know. But maybe the webview could be
> >> based on the Chromium project (the engine behind Chrome browser), to cut
> >> corners and development time and to have more features than the current
> one
> >> has. There many projects based on Chromium (e.g: Electron a cross
> platform
> >> solution for building apps, etc).
> >>
> >> In fact there is a project called JCEF, which renders the Chromium
> browser
> >> into a Swing application.
> >> Perhaps John you could even already use this in your JavaFX apps.
> >>
> >> My 2 cents,
> >>
> >>> On Sat, Oct 13, 2018 at 3:20 AM John-Val Rose <johnvalrose at gmail.com>
> wrote:
> >>>
> >>> I know I have mentioned this numerous times but maybe this list is the
> best
> >>> place to discuss this particular (missing) feature.
> >>>
> >>> For our needs, there are so many reasons why we could really benefit
> from
> >>> WebGL support even if, as I've also said before, it were only to enable
> >>> Google Maps to work in "full" mode.
> >>>
> >>> What do others think about this?  Am I the only one who feels the need
> for
> >>> WebGL as a *priority* feature?
> >>>
> >>> Yes, I do understand that it's not as simple as just "turning it on"
> and
> >>> does open-up the even larger discussion about JavaFX supporting all the
> >>> major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.
> >>>
> >>> So, can we discuss this?  I would really like to get responses from
> people
> >>> who have opinions on the merits of WebGL support and also anyone who
> has
> >>> the skills/knowledge to best suggest a means of getting this feature
> >>> implemented.
> >>>
> >>> Graciously,
> >>>
> >>> John-Val Rose
> >>> Chief Scientist/Architect
> >>> Rosethorn Technology
> >>> Australia
> >>>
> >>
> >>
> >> --
> >> Pedro Duque Vieira - https://www.pixelduke.com
> >
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From johnvalrose at gmail.com  Mon Oct 15 16:11:49 2018
From: johnvalrose at gmail.com (John-Val Rose)
Date: Tue, 16 Oct 2018 03:11:49 +1100
Subject: The case for WebGL support
In-Reply-To: <CAAEud6bmg3644LdHTTQAa4XmkAHEBwXskJzF8Ntj5C6sA=xUUg@mail.gmail.com>
References: <CAFKr6yxckA2q17iXqtuGRNj=cs_TgJh0N5Wsc=33z7kOGGfPhw@mail.gmail.com>
 <CAAEud6ZF_LUn_Q2e2NuRC1H0Xj3OzQN3_JTDTtw6hEQqWE7zcA@mail.gmail.com>
 <94A8EFE9-F692-4F6E-AF22-EA47BFFFA56B@bestsolution.at>
 <72BD1C43-068E-42A8-A278-237FF4C8A489@gmail.com>
 <CAAEud6bmg3644LdHTTQAa4XmkAHEBwXskJzF8Ntj5C6sA=xUUg@mail.gmail.com>
Message-ID: <44CA4562-47C9-4EFA-8BA2-00D0A88A4C61@gmail.com>

Yes - I hope so.

But TeamDev (the authors of JxBrowser) have no current plan to port their very high quality product to mobile platforms.

> On 16 Oct 2018, at 03:08, Pedro Duque Vieira <pedro.duquevieira at gmail.com> wrote:
> 
> Hi John, and others,
> 
> Chromium runs on ios and android so probably, technically, it should be possible to have it run in the future through JavaFX too.
> 
> Cheers,
> 
>> On Mon, Oct 15, 2018 at 5:05 PM John-Val Rose <johnvalrose at gmail.com> wrote:
>> Hi Pedro,
>> 
>> I?m actually using the commercial product known as JxBrowser (for our first commercial JavaFX based product) which is basically a Java wrapper around Chromium and works amazingly well.
>> 
>> But it?s not portable to either iOS or Android which is a ?headache? to say the least.
>> 
>> Graciously,
>> 
>> John-Val
>> 
>> > On 14 Oct 2018, at 02:01, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>> > 
>> > Hi,
>> > 
>> > I think Pedro is right rather than investing into WebGL for WebView I?d invest in using CEF. I think CEF can render offscreen and you can get that Texture ID.
>> > 
>> > The missing piece then is that we need a way to map native textures into FX - if only someone would work on that :-)
>> > 
>> > Tom
>> > 
>> > Von meinem iPhone gesendet
>> > 
>> >> Am 13.10.2018 um 15:48 schrieb Pedro Duque Vieira <pedro.duquevieira at gmail.com>:
>> >> 
>> >> Not talking about whether this is a needed feature or not, or whether there
>> >> is demand for it, because I don't know. But maybe the webview could be
>> >> based on the Chromium project (the engine behind Chrome browser), to cut
>> >> corners and development time and to have more features than the current one
>> >> has. There many projects based on Chromium (e.g: Electron a cross platform
>> >> solution for building apps, etc).
>> >> 
>> >> In fact there is a project called JCEF, which renders the Chromium browser
>> >> into a Swing application.
>> >> Perhaps John you could even already use this in your JavaFX apps.
>> >> 
>> >> My 2 cents,
>> >> 
>> >>> On Sat, Oct 13, 2018 at 3:20 AM John-Val Rose <johnvalrose at gmail.com> wrote:
>> >>> 
>> >>> I know I have mentioned this numerous times but maybe this list is the best
>> >>> place to discuss this particular (missing) feature.
>> >>> 
>> >>> For our needs, there are so many reasons why we could really benefit from
>> >>> WebGL support even if, as I've also said before, it were only to enable
>> >>> Google Maps to work in "full" mode.
>> >>> 
>> >>> What do others think about this?  Am I the only one who feels the need for
>> >>> WebGL as a *priority* feature?
>> >>> 
>> >>> Yes, I do understand that it's not as simple as just "turning it on" and
>> >>> does open-up the even larger discussion about JavaFX supporting all the
>> >>> major graphics APIs like OpenGL, Direct3D, Metal & Vulkan.
>> >>> 
>> >>> So, can we discuss this?  I would really like to get responses from people
>> >>> who have opinions on the merits of WebGL support and also anyone who has
>> >>> the skills/knowledge to best suggest a means of getting this feature
>> >>> implemented.
>> >>> 
>> >>> Graciously,
>> >>> 
>> >>> John-Val Rose
>> >>> Chief Scientist/Architect
>> >>> Rosethorn Technology
>> >>> Australia
>> >>> 
>> >> 
>> >> 
>> >> -- 
>> >> Pedro Duque Vieira - https://www.pixelduke.com
>> > 
> 
> 
> -- 
> Pedro Duque Vieira - https://www.pixelduke.com

From pavelkasotov at gmail.com  Thu Oct 18 11:11:58 2018
From: pavelkasotov at gmail.com (Pavel Kasotov)
Date: Thu, 18 Oct 2018 14:11:58 +0300
Subject: JDK-8092297: Implement Serializable in Properties
Message-ID: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>

Hi all,

I suggest to increase the priority of the issue JDK-8092297. My 
suggestion I explain
this way - without possibility to serialize Properties it is rather 
difficult to use JavaFX
for enterprise applications that in most cases use a client-server 
architecture.

For example, there is a RMI client and a server and from the server we 
need to pass
some User. In order we could do it we need User were serializable. If we 
want
to use JavaFX we would like to do the following:

class User implements Serializable {

 ??????? private final StringProperty name = new SimpleStringProperty();
 ??????? ....
}

However it won't work because properties are not serializable. So, we 
have two workarounds:
1) implement writeObject() and readObject()
2) make User with String and implement UserAdapter

Both ways are not good because they require a lot of manual work and 
make solution more
difficult.

Best regards, Pavel

From kevin.rushforth at oracle.com  Thu Oct 18 11:25:27 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Thu, 18 Oct 2018 04:25:27 -0700
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
Message-ID: <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>

I think implementing this would be a mistake, especially given that the 
long-term direction for Java is to move away from the existing 
serialization mechanism. There have many discussions on the security and 
integrity problems with the Java serialization, so I won't rehash them here.

It might be best to close JDK-8092297 as "Won't fix" so no one is under 
any illusion that this is likely to happen.

-- Kevin


On 10/18/2018 4:11 AM, Pavel Kasotov wrote:
> Hi all,
>
> I suggest to increase the priority of the issue JDK-8092297. My 
> suggestion I explain
> this way - without possibility to serialize Properties it is rather 
> difficult to use JavaFX
> for enterprise applications that in most cases use a client-server 
> architecture.
>
> For example, there is a RMI client and a server and from the server we 
> need to pass
> some User. In order we could do it we need User were serializable. If 
> we want
> to use JavaFX we would like to do the following:
>
> class User implements Serializable {
>
> ??????? private final StringProperty name = new SimpleStringProperty();
> ??????? ....
> }
>
> However it won't work because properties are not serializable. So, we 
> have two workarounds:
> 1) implement writeObject() and readObject()
> 2) make User with String and implement UserAdapter
>
> Both ways are not good because they require a lot of manual work and 
> make solution more
> difficult.
>
> Best regards, Pavel


From tom.schindl at bestsolution.at  Thu Oct 18 11:45:50 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 18 Oct 2018 13:45:50 +0200
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
 <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
Message-ID: <a8bd645f-13f4-5e74-a47b-a6d2cbc0479c@bestsolution.at>

On 18.10.18 13:25, Kevin Rushforth wrote:
> I think implementing this would be a mistake, especially given that the
> long-term direction for Java is to move away from the existing
> serialization mechanism. There have many discussions on the security and
> integrity problems with the Java serialization, so I won't rehash them
> here.
> 
> It might be best to close JDK-8092297 as "Won't fix" so no one is under
> any illusion that this is likely to happen.

+1

Tom

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From pavelkasotov at gmail.com  Thu Oct 18 12:25:31 2018
From: pavelkasotov at gmail.com (Pavel Kasotov)
Date: Thu, 18 Oct 2018 15:25:31 +0300
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
Message-ID: <a58004cc-6fb2-ec31-0d30-67a5fdc07a9f@gmail.com>

Kevin,

Thank you very much for quick answer and detailed explanation.

I think that opening openjfx-discuss was a great idea because finally
we could establish feedback with javafx developers.

Best regards, Pavel



From nlisker at gmail.com  Thu Oct 18 12:33:54 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 18 Oct 2018 15:33:54 +0300
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <a58004cc-6fb2-ec31-0d30-67a5fdc07a9f@gmail.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
 <a58004cc-6fb2-ec31-0d30-67a5fdc07a9f@gmail.com>
Message-ID: <CA+0ynh_9ZjKOr+G_43t9s6m7puwfiX29kui7emLB1dkoT2GubA@mail.gmail.com>

Hi Pavel,

You might want to try another workaround option using Externalizable.
There's an example on SO [1].

[1]
https://stackoverflow.com/questions/23187989/using-javafx-beans-properties-in-model-classes


On Thu, Oct 18, 2018 at 3:26 PM Pavel Kasotov <pavelkasotov at gmail.com>
wrote:

> Kevin,
>
> Thank you very much for quick answer and detailed explanation.
>
> I think that opening openjfx-discuss was a great idea because finally
> we could establish feedback with javafx developers.
>
> Best regards, Pavel
>
>
>

From nlisker at gmail.com  Thu Oct 18 14:08:17 2018
From: nlisker at gmail.com (Nir Lisker)
Date: Thu, 18 Oct 2018 17:08:17 +0300
Subject: 3D Canvas Node
Message-ID: <CA+0ynh8MsDz1e67GyE23AuKvQef7P55HY+j==35ruFXFBaG9RA@mail.gmail.com>

(In continuation of the openjfx-dev discussion [1])

I agree that there is a need for it. As usual, the question is who is
willing to work on this?

[1]
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022683.html

From venatorxoa at gmail.com  Thu Oct 18 14:13:53 2018
From: venatorxoa at gmail.com (Vincent MOLLIERE)
Date: Thu, 18 Oct 2018 16:13:53 +0200
Subject: 3D Canvas Node
In-Reply-To: <CA+0ynh8MsDz1e67GyE23AuKvQef7P55HY+j==35ruFXFBaG9RA@mail.gmail.com>
References: <CA+0ynh8MsDz1e67GyE23AuKvQef7P55HY+j==35ruFXFBaG9RA@mail.gmail.com>
Message-ID: <CALvxMvsyX+Kxc0FcT4aBm3XwrniQwX5LOk1NeC3N9bKNog4__w@mail.gmail.com>

What is a 3d canvas ?

Le jeu. 18 oct. 2018 ? 16:09, Nir Lisker <nlisker at gmail.com> a ?crit :

> (In continuation of the openjfx-dev discussion [1])
>
> I agree that there is a need for it. As usual, the question is who is
> willing to work on this?
>
> [1]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-October/022683.html
>

From david.goodenough at linkchoose.co.uk  Thu Oct 18 11:38:55 2018
From: david.goodenough at linkchoose.co.uk (David Goodenough)
Date: Thu, 18 Oct 2018 12:38:55 +0100
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
 <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
Message-ID: <2700959.3Kya5gL27u@continuum>

Is there a public plan for the new serialization mechanism.  Is there a public discussion 
of the new mechanism, are there any prototypes, is there any idea when about a 
timescale for its adoption (subject to all the usual caveats)?

David

On Thursday, 18 October 2018 12:25:27 BST Kevin Rushforth wrote:
> I think implementing this would be a mistake, especially given that the
> long-term direction for Java is to move away from the existing
> serialization mechanism. There have many discussions on the security and
> integrity problems with the Java serialization, so I won't rehash them here.
> 
> It might be best to close JDK-8092297 as "Won't fix" so no one is under
> any illusion that this is likely to happen.
> 
> -- Kevin
> 
> On 10/18/2018 4:11 AM, Pavel Kasotov wrote:
> > Hi all,
> > 
> > I suggest to increase the priority of the issue JDK-8092297. My
> > suggestion I explain
> > this way - without possibility to serialize Properties it is rather
> > difficult to use JavaFX
> > for enterprise applications that in most cases use a client-server
> > architecture.
> > 
> > For example, there is a RMI client and a server and from the server we
> > need to pass
> > some User. In order we could do it we need User were serializable. If
> > we want
> > to use JavaFX we would like to do the following:
> > 
> > class User implements Serializable {
> > 
> >         private final StringProperty name = new SimpleStringProperty();
> >         ....
> > }
> > 
> > However it won't work because properties are not serializable. So, we
> > have two workarounds:
> > 1) implement writeObject() and readObject()
> > 2) make User with String and implement UserAdapter
> > 
> > Both ways are not good because they require a lot of manual work and
> > make solution more
> > difficult.
> > 
> > Best regards, Pavel



From amnojeeuw at gmail.com  Fri Oct 19 04:54:48 2018
From: amnojeeuw at gmail.com (Amno Jeeuw)
Date: Fri, 19 Oct 2018 00:54:48 -0400
Subject: openjfx source builds
Message-ID: <CAKX+xxGXJEFKHi1UB2+Bzq8LeV7MOaNerGQ5w6=mZOGQoZsp-g@mail.gmail.com>

Is there a place where I can download a OpenJFX installer?
Any help would be appreciated.


*ArbolOne
Using Fire Fox and Thunderbird.
Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
platform has been exciting and most rewarding.
[ ? ]*

From matthieu at brouillard.fr  Fri Oct 19 05:14:53 2018
From: matthieu at brouillard.fr (Matthieu BROUILLARD)
Date: Fri, 19 Oct 2018 07:14:53 +0200
Subject: openjfx source builds
In-Reply-To: <CAKX+xxGXJEFKHi1UB2+Bzq8LeV7MOaNerGQ5w6=mZOGQoZsp-g@mail.gmail.com>
References: <CAKX+xxGXJEFKHi1UB2+Bzq8LeV7MOaNerGQ5w6=mZOGQoZsp-g@mail.gmail.com>
Message-ID: <CADsuJr8moD3wjOv5bZ71p1p6kj4w80s-cUwM4iDP-9ppHzs9wQ@mail.gmail.com>

You should find some instructions on https://openjfx.io/.

Matthieu

On Fri, Oct 19, 2018 at 6:55 AM Amno Jeeuw <amnojeeuw at gmail.com> wrote:

> Is there a place where I can download a OpenJFX installer?
> Any help would be appreciated.
>
>
> *ArbolOne
> Using Fire Fox and Thunderbird.
> Developing for Android using Java, C/C++, HTM/CSS and SQLite as our
> platform has been exciting and most rewarding.
> [ ? ]*
>

From david.goodenough at broadwellmanor.co.uk  Thu Oct 18 11:38:17 2018
From: david.goodenough at broadwellmanor.co.uk (David Goodenough)
Date: Thu, 18 Oct 2018 12:38:17 +0100
Subject: JDK-8092297: Implement Serializable in Properties
In-Reply-To: <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
References: <ebf82c99-6a23-d142-90d6-c11d1a35e9f6@gmail.com>
 <9b699ae1-850b-a86d-c426-5515490cb151@oracle.com>
Message-ID: <41622087.osbEoUBaPf@continuum>

Is there a public plan for the new serialization mechanism.  Is there a public discussion 
of the new mechanism, are there any prototypes, is there any idea when about a 
timescale for its adoption (subject to all the usual caveats)?

David

On Thursday, 18 October 2018 12:25:27 BST Kevin Rushforth wrote:
> I think implementing this would be a mistake, especially given that the
> long-term direction for Java is to move away from the existing
> serialization mechanism. There have many discussions on the security and
> integrity problems with the Java serialization, so I won't rehash them here.
> 
> It might be best to close JDK-8092297 as "Won't fix" so no one is under
> any illusion that this is likely to happen.
> 
> -- Kevin
> 
> On 10/18/2018 4:11 AM, Pavel Kasotov wrote:
> > Hi all,
> > 
> > I suggest to increase the priority of the issue JDK-8092297. My
> > suggestion I explain
> > this way - without possibility to serialize Properties it is rather
> > difficult to use JavaFX
> > for enterprise applications that in most cases use a client-server
> > architecture.
> > 
> > For example, there is a RMI client and a server and from the server we
> > need to pass
> > some User. In order we could do it we need User were serializable. If
> > we want
> > to use JavaFX we would like to do the following:
> > 
> > class User implements Serializable {
> > 
> >         private final StringProperty name = new SimpleStringProperty();
> >         ....
> > }
> > 
> > However it won't work because properties are not serializable. So, we
> > have two workarounds:
> > 1) implement writeObject() and readObject()
> > 2) make User with String and implement UserAdapter
> > 
> > Both ways are not good because they require a lot of manual work and
> > make solution more
> > difficult.
> > 
> > Best regards, Pavel



From ooo_saturn7 at mail.ru  Sat Oct 20 11:46:41 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Sat, 20 Oct 2018 14:46:41 +0300
Subject: =?UTF-8?B?Q2FuIHdlIGJpbmQgYSBwcm9wZXJ0eSB1bmlkaXJlY3Rpb25hbGx5IG9ubHkg?=
 =?UTF-8?B?d2l0aCBvbmUgcHJvcGVydHkgYW5kIGJpbmQgYmlkaXJlY3Rpb25hbGx5IHdp?=
 =?UTF-8?B?dGggbWFueSBwcm9wZXJ0aWVzPw==?=
Message-ID: <1540036001.918181464@f547.i.mail.ru>

Hi all,

I am trying to understand two methods of Property<T> interface:
?? Property#unbind()? 
?? Property#unbindBidirectional(Property<T> other) 

Can anyone say if it is true that we can bind a property unidirectionally only with one property 
and bind bidirectionally with many properties? If yes, then how to explain it?

Best regards, Alex

From ooo_saturn7 at mail.ru  Sat Oct 20 12:21:55 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Sat, 20 Oct 2018 15:21:55 +0300
Subject: =?UTF-8?B?SkRLLTgwOTIyOTc6IEltcGxlbWVudCBTZXJpYWxpemFibGUgaW4gUHJvcGVy?=
 =?UTF-8?B?dGllcw==?=
In-Reply-To: <mailman.27.1540036801.20996.openjfx-discuss@openjdk.java.net>
References: <mailman.27.1540036801.20996.openjfx-discuss@openjdk.java.net>
Message-ID: <1540038115.347795074@f365.i.mail.ru>

I think that serialization mechanism will be removed from JDK not soon.
Besides, as I hear there will be provided another solution for serialization.
For example, how can RMI work without serialization?

That's why I suggest TO IMPLEMENT this feature but NOT TO CLOSE IT.
And when new?serialization framework will be ready move JavaFX to that
framework.

>
>Is there a public plan for the new serialization mechanism.  Is there a public discussion 
>of the new mechanism, are there any prototypes, is there any idea when about a 
>timescale for its adoption (subject to all the usual caveats)?
>
>David
>
>On Thursday, 18 October 2018 12:25:27 BST Kevin Rushforth wrote:
>> I think implementing this would be a mistake, especially given that the
>> long-term direction for Java is to move away from the existing
>> serialization mechanism. There have many discussions on the security and
>> integrity problems with the Java serialization, so I won't rehash them here.
>> 
>> It might be best to close JDK-8092297 as "Won't fix" so no one is under
>> any illusion that this is likely to happen.
>> 
>> -- Kevin

-- 
Alex Sviridov

From pavelkastornyy at gmail.com  Wed Oct 24 06:27:51 2018
From: pavelkastornyy at gmail.com (=?UTF-8?B?0JrQsNGB0YLQvtGA0L3Ri9C5INCf0LDQstC10Ls=?=)
Date: Wed, 24 Oct 2018 09:27:51 +0300
Subject: Porting OpenJFX API to TypeScript
Message-ID: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>

Hi all,

I want to port OpenJFX API to TypeScript in order to use the similar API 
when developing
an application on OpenJFX and TypeScript(JavaScript for web browsers). 
Of course ported
OpenJFX API will be simplified and modified. And I have several questions:

1) May I do it?

2) As I understand, for the code I will write I MUST use GNU General 
Public License, version 2,
with the Classpath Exception. Am I right?

3) What copyright and license header must I use in my files?

-- 
Best regards, Pavel

From tom.schindl at bestsolution.at  Wed Oct 24 06:54:35 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 24 Oct 2018 08:54:35 +0200
Subject: Porting OpenJFX API to TypeScript
In-Reply-To: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>
References: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>
Message-ID: <18ff8ace-36d5-6bfe-9aec-71379fd33259@bestsolution.at>

Hi,

I can not comment on licensing but Gerrit and me did some experiments on
porting OpenJFX to SVG [1] - we also looked at HTML but the code is not
there anymore I think.

This is just a PoC so codewise, ... not yet ready. The biggest problem
when porting to the web is that Web-CSS does not allow you to define
custom attributes.

After the PoC I decided that the first thing you need is a better
abstraction on the SVG level first [2| and I'm working on that now and then.

Tom

[1]https://github.com/tomsontom/webfx

On 24.10.18 08:27, ????????? ????? wrote:
> Hi all,
> 
> I want to port OpenJFX API to TypeScript in order to use the similar API
> when developing
> an application on OpenJFX and TypeScript(JavaScript for web browsers).
> Of course ported
> OpenJFX API will be simplified and modified. And I have several questions:
> 
> 1) May I do it?
> 
> 2) As I understand, for the code I will write I MUST use GNU General
> Public License, version 2,
> with the Classpath Exception. Am I right?
> 
> 3) What copyright and license header must I use in my files?
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From tom.schindl at bestsolution.at  Wed Oct 24 07:04:43 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Wed, 24 Oct 2018 09:04:43 +0200
Subject: Porting OpenJFX API to TypeScript
In-Reply-To: <18ff8ace-36d5-6bfe-9aec-71379fd33259@bestsolution.at>
References: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>
 <18ff8ace-36d5-6bfe-9aec-71379fd33259@bestsolution.at>
Message-ID: <54029c85-2084-7394-b7a7-8bafb30c3b46@bestsolution.at>

[2]https://github.com/BestSolution-at/svgkit/

On 24.10.18 08:54, Tom Schindl wrote:
> Hi,
> 
> I can not comment on licensing but Gerrit and me did some experiments on
> porting OpenJFX to SVG [1] - we also looked at HTML but the code is not
> there anymore I think.
> 
> This is just a PoC so codewise, ... not yet ready. The biggest problem
> when porting to the web is that Web-CSS does not allow you to define
> custom attributes.
> 
> After the PoC I decided that the first thing you need is a better
> abstraction on the SVG level first [2| and I'm working on that now and then.
> 
> Tom
> 
> [1]https://github.com/tomsontom/webfx
> 
> On 24.10.18 08:27, ????????? ????? wrote:
>> Hi all,
>>
>> I want to port OpenJFX API to TypeScript in order to use the similar API
>> when developing
>> an application on OpenJFX and TypeScript(JavaScript for web browsers).
>> Of course ported
>> OpenJFX API will be simplified and modified. And I have several questions:
>>
>> 1) May I do it?
>>
>> 2) As I understand, for the code I will write I MUST use GNU General
>> Public License, version 2,
>> with the Classpath Exception. Am I right?
>>
>> 3) What copyright and license header must I use in my files?
>>
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From philip.race at oracle.com  Wed Oct 24 07:09:13 2018
From: philip.race at oracle.com (Philip Race)
Date: Wed, 24 Oct 2018 00:09:13 -0700
Subject: Porting OpenJFX API to TypeScript
In-Reply-To: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>
References: <810ae237-2e71-912f-d3c2-fdb78dcd78bd@gmail.com>
Message-ID: <5BD01A99.4000205@oracle.com>

You are asking for legal advice. So you need a lawyer.

-phil.

On 10/23/18, 11:27 PM, ????????? ????? wrote:
> Hi all,
>
> I want to port OpenJFX API to TypeScript in order to use the similar 
> API when developing
> an application on OpenJFX and TypeScript(JavaScript for web browsers). 
> Of course ported
> OpenJFX API will be simplified and modified. And I have several 
> questions:
>
> 1) May I do it?
>
> 2) As I understand, for the code I will write I MUST use GNU General 
> Public License, version 2,
> with the Classpath Exception. Am I right?
>
> 3) What copyright and license header must I use in my files?
>

From pmonks at gmail.com  Thu Oct 25 01:15:55 2018
From: pmonks at gmail.com (Peter Monks)
Date: Wed, 24 Oct 2018 18:15:55 -0700
Subject: OpenJFX versions - will they always track to JDK versions?
Message-ID: <CAN8FOXq9VJ_MidS9SGHmGOL6T7r+YvVPVKz64_wRooUEhgZO6Q@mail.gmail.com>

G'day!

Just wondering whether OpenJFX's versions are always going to track to
specific JDK versions, or whether the plan is for OpenJFX versions to
decouple from JDK versions over time?

>From a downstream consumer's perspective, it would be ideal if OpenJFX were
to decouple from the JDK, and provide some kind of version compatibility
matrix as new OpenJFX and JDK versions are released.  This is how most Java
libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
with that assumption in mind.

Thanks in advance for any light you're able to shed on this topic!

Cheers,
Peter

From tom.schindl at bestsolution.at  Thu Oct 25 06:46:10 2018
From: tom.schindl at bestsolution.at (Tom Schindl)
Date: Thu, 25 Oct 2018 08:46:10 +0200
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <CAN8FOXq9VJ_MidS9SGHmGOL6T7r+YvVPVKz64_wRooUEhgZO6Q@mail.gmail.com>
References: <CAN8FOXq9VJ_MidS9SGHmGOL6T7r+YvVPVKz64_wRooUEhgZO6Q@mail.gmail.com>
Message-ID: <d156ef2d-dbb5-94fb-4c7f-5225b5a591f0@bestsolution.at>

Hi,

See
http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022527.html

Tom

On 25.10.18 03:15, Peter Monks wrote:
> G'day!
> 
> Just wondering whether OpenJFX's versions are always going to track to
> specific JDK versions, or whether the plan is for OpenJFX versions to
> decouple from JDK versions over time?
> 
> From a downstream consumer's perspective, it would be ideal if OpenJFX were
> to decouple from the JDK, and provide some kind of version compatibility
> matrix as new OpenJFX and JDK versions are released.  This is how most Java
> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
> with that assumption in mind.
> 
> Thanks in advance for any light you're able to shed on this topic!
> 
> Cheers,
> Peter
> 

-- 
Tom Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From pmonks at gmail.com  Thu Oct 25 14:07:26 2018
From: pmonks at gmail.com (Peter Monks)
Date: Thu, 25 Oct 2018 07:07:26 -0700
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <d156ef2d-dbb5-94fb-4c7f-5225b5a591f0@bestsolution.at>
References: <CAN8FOXq9VJ_MidS9SGHmGOL6T7r+YvVPVKz64_wRooUEhgZO6Q@mail.gmail.com>
 <d156ef2d-dbb5-94fb-4c7f-5225b5a591f0@bestsolution.at>
Message-ID: <21001CAA-9590-4D92-A3EB-74C1904E466D@gmail.com>

Thanks Tom.

That thread seems to somewhat conflate two different topics:
1. JDK version(s) required to build OpenJFX
2. JDK version(s) required to run OpenJFX

As a consumer of OpenJFX, I am primarily interested in #2, and this paragraph from the thread [1] approximates my preference:

?To be clear, I'm not that concerned about breaking compatibility with older versions of the JDK because of API updates/introductions/removals or new, better tools being introduced. I'm more concerned about backwards compatibility being broken for stupid reasons like new lazy  language updates that have no actual value or can be done with older compatible ways?

i.e. it would be ideal if newer versions of OpenJFX continued to function on older versions of the JDK, where that doesn?t functionally cripple OpenJFX

I don?t see a definitive answer to my question in that thread yet, but I?ll keep an eye on it.  If there are more appropriate forums in which I, as a consumer, can express my requirements I?d be keen to hear about that too.

Thanks again,
Peter

[1] http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022549.html



> On Oct 24, 2018, at 11:46 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:
> 
> Hi,
> 
> See
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022527.html
> 
> Tom
> 
>> On 25.10.18 03:15, Peter Monks wrote:
>> G'day!
>> 
>> Just wondering whether OpenJFX's versions are always going to track to
>> specific JDK versions, or whether the plan is for OpenJFX versions to
>> decouple from JDK versions over time?
>> 
>> From a downstream consumer's perspective, it would be ideal if OpenJFX were
>> to decouple from the JDK, and provide some kind of version compatibility
>> matrix as new OpenJFX and JDK versions are released.  This is how most Java
>> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
>> with that assumption in mind.
>> 
>> Thanks in advance for any light you're able to shed on this topic!
>> 
>> Cheers,
>> Peter
>> 
> 
> -- 
> Tom Schindl, CTO
> BestSolution.at EDV Systemhaus GmbH
> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

From kevin.rushforth at oracle.com  Fri Oct 26 21:55:33 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Fri, 26 Oct 2018 14:55:33 -0700
Subject: Oracle Code One JavaFX.next slides
Message-ID: <7dd21605-59d6-f094-db81-29a72da65f99@oracle.com>

Here is a pointer the slides we presented at this week's Oracle Code One 
conference, in case anyone is interested:

http://cr.openjdk.java.net/~kcr/presentations/code-one-2018/JavaFXNext.pdf

-- Kevin


From bourges.laurent at gmail.com  Sat Oct 27 10:06:12 2018
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Sat, 27 Oct 2018 12:06:12 +0200
Subject: Oracle Code One JavaFX.next slides
In-Reply-To: <7dd21605-59d6-f094-db81-29a72da65f99@oracle.com>
References: <7dd21605-59d6-f094-db81-29a72da65f99@oracle.com>
Message-ID: <CAKjRUT4PxtQSbb9S4Rakz+0zAgsmEb2N1M+VgqcKVFwrR-YZXQ@mail.gmail.com>

Thanks,
What your talk recorded ?

Laurent

Le ven. 26 oct. 2018 ? 23:56, Kevin Rushforth <kevin.rushforth at oracle.com>
a ?crit :

> Here is a pointer the slides we presented at this week's Oracle Code One
> conference, in case anyone is interested:
>
> http://cr.openjdk.java.net/~kcr/presentations/code-one-2018/JavaFXNext.pdf
>
> -- Kevin
>
>

From kevin.rushforth at oracle.com  Sat Oct 27 12:13:42 2018
From: kevin.rushforth at oracle.com (Kevin Rushforth)
Date: Sat, 27 Oct 2018 05:13:42 -0700
Subject: Oracle Code One JavaFX.next slides
In-Reply-To: <CAKjRUT4PxtQSbb9S4Rakz+0zAgsmEb2N1M+VgqcKVFwrR-YZXQ@mail.gmail.com>
References: <7dd21605-59d6-f094-db81-29a72da65f99@oracle.com>
 <CAKjRUT4PxtQSbb9S4Rakz+0zAgsmEb2N1M+VgqcKVFwrR-YZXQ@mail.gmail.com>
Message-ID: <92ed0574-0f6f-9b17-f8b5-e9d6bdb43443@oracle.com>

Unfortunately, no. Most of the rooms did not have video recording.

-- Kevin


On 10/27/2018 3:06 AM, Laurent Bourg?s wrote:
> Thanks,
> What your talk recorded ?
>
> Laurent
>
> Le ven. 26 oct. 2018 ? 23:56, Kevin Rushforth 
> <kevin.rushforth at oracle.com <mailto:kevin.rushforth at oracle.com>> a ?crit?:
>
>     Here is a pointer the slides we presented at this week's Oracle
>     Code One
>     conference, in case anyone is interested:
>
>     http://cr.openjdk.java.net/~kcr/presentations/code-one-2018/JavaFXNext.pdf
>     <http://cr.openjdk.java.net/%7Ekcr/presentations/code-one-2018/JavaFXNext.pdf>
>
>     -- Kevin
>


From pedro.duquevieira at gmail.com  Sat Oct 27 13:42:45 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Sat, 27 Oct 2018 14:42:45 +0100
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <21001CAA-9590-4D92-A3EB-74C1904E466D@gmail.com>
References: <CAN8FOXq9VJ_MidS9SGHmGOL6T7r+YvVPVKz64_wRooUEhgZO6Q@mail.gmail.com>
 <d156ef2d-dbb5-94fb-4c7f-5225b5a591f0@bestsolution.at>
 <21001CAA-9590-4D92-A3EB-74C1904E466D@gmail.com>
Message-ID: <CAAEud6Y9oZ57q5xTR-zv3aAHF5gYTkcPyJzQj0oBygXcuSHpkg@mail.gmail.com>

The plan seems to be that OpenJFX(N) will run on OpenJDK(N) and
OpenJDK(N-1) and make no efforts to support or break usage in OpenJDK(N-2):
so no guarantees of it either running or not on OpenJDK(N-2).

I suggested that this would be instead decided on a version by version
basis (especially when, for example, nowadays the vast majority of
developers are still on Java8 - big effort may be required for them to move
to java9+), but this seems to be the plan.

Cheers,

On Thu, Oct 25, 2018 at 3:08 PM Peter Monks <pmonks at gmail.com> wrote:

> Thanks Tom.
>
> That thread seems to somewhat conflate two different topics:
> 1. JDK version(s) required to build OpenJFX
> 2. JDK version(s) required to run OpenJFX
>
> As a consumer of OpenJFX, I am primarily interested in #2, and this
> paragraph from the thread [1] approximates my preference:
>
> ?To be clear, I'm not that concerned about breaking compatibility with
> older versions of the JDK because of API updates/introductions/removals or
> new, better tools being introduced. I'm more concerned about backwards
> compatibility being broken for stupid reasons like new lazy  language
> updates that have no actual value or can be done with older compatible ways?
>
> i.e. it would be ideal if newer versions of OpenJFX continued to function
> on older versions of the JDK, where that doesn?t functionally cripple
> OpenJFX
>
> I don?t see a definitive answer to my question in that thread yet, but
> I?ll keep an eye on it.  If there are more appropriate forums in which I,
> as a consumer, can express my requirements I?d be keen to hear about that
> too.
>
> Thanks again,
> Peter
>
> [1]
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022549.html
>
>
>
> > On Oct 24, 2018, at 11:46 PM, Tom Schindl <tom.schindl at bestsolution.at>
> wrote:
> >
> > Hi,
> >
> > See
> >
> http://mail.openjdk.java.net/pipermail/openjfx-dev/2018-September/022527.html
> >
> > Tom
> >
> >> On 25.10.18 03:15, Peter Monks wrote:
> >> G'day!
> >>
> >> Just wondering whether OpenJFX's versions are always going to track to
> >> specific JDK versions, or whether the plan is for OpenJFX versions to
> >> decouple from JDK versions over time?
> >>
> >> From a downstream consumer's perspective, it would be ideal if OpenJFX
> were
> >> to decouple from the JDK, and provide some kind of version compatibility
> >> matrix as new OpenJFX and JDK versions are released.  This is how most
> Java
> >> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
> >> with that assumption in mind.
> >>
> >> Thanks in advance for any light you're able to shed on this topic!
> >>
> >> Cheers,
> >> Peter
> >>
> >
> > --
> > Tom Schindl, CTO
> > BestSolution.at EDV Systemhaus GmbH
> > Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
> > Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From pmonks at gmail.com  Mon Oct 22 19:09:43 2018
From: pmonks at gmail.com (Peter Monks)
Date: Mon, 22 Oct 2018 12:09:43 -0700
Subject: OpenJFX versions - will they always track to JDK versions?
Message-ID: <CAN8FOXoJekdju-HmwbtL1ibJPcZS0CW39+B9NRHv2kTbL+D7fg@mail.gmail.com>

G'day!

Just wondering whether OpenJFX's versions are always going to track to
specific JDK versions, or whether the plan is for OpenJFX versions to
decouple from JDK versions over time?

>From a downstream consumer's perspective, it would be ideal if OpenJFX were
to decouple from the JDK, and provide some kind of version compatibility
matrix as new OpenJFX and JDK versions are released.  This is how most Java
libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
with that assumption.

Thanks in advance for any light you're able to shed on this topic!

Cheers,
Peter

From michael.anderl at gmail.com  Sun Oct 28 18:24:04 2018
From: michael.anderl at gmail.com (Michael Anderl)
Date: Sun, 28 Oct 2018 19:24:04 +0100
Subject: openjfx and shadowjar bigjar
Message-ID: <CAE2cSpeqJQ=xncq_7DxP_nqAFNHf7M3Hg33Vn2=_eRfBCED2dQ@mail.gmail.com>

Is it possible to build a jar for openjdk11 with openjfx11 inside?
(with the gadle tool shadowjar)
I am able to make a jar with all the javafx.* classes inside, but with
java -jar test.jar I get
Error: JavaFX runtime components are missing, and are required to run
this application

Is somewhere a tutorial with a multi release onebigfatjar for java8 &
java11 and java11 has all the javafx stuff inside? is this even
possible?

thx
mike

From pedro.duquevieira at gmail.com  Tue Oct 30 15:38:10 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 30 Oct 2018 15:38:10 +0000
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <CAN8FOXoJekdju-HmwbtL1ibJPcZS0CW39+B9NRHv2kTbL+D7fg@mail.gmail.com>
References: <CAN8FOXoJekdju-HmwbtL1ibJPcZS0CW39+B9NRHv2kTbL+D7fg@mail.gmail.com>
Message-ID: <CAAEud6YFuJzoyw0jTtJrDG1bXqDf3bM6u+4R1Sr2ff50+dKH3A@mail.gmail.com>

Hi Peter,

I've already answered you on this.

Cheers,

On Sun, Oct 28, 2018 at 6:29 PM Peter Monks <pmonks at gmail.com> wrote:

> G'day!
>
> Just wondering whether OpenJFX's versions are always going to track to
> specific JDK versions, or whether the plan is for OpenJFX versions to
> decouple from JDK versions over time?
>
> From a downstream consumer's perspective, it would be ideal if OpenJFX were
> to decouple from the JDK, and provide some kind of version compatibility
> matrix as new OpenJFX and JDK versions are released.  This is how most Java
> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
> with that assumption.
>
> Thanks in advance for any light you're able to shed on this topic!
>
> Cheers,
> Peter
>


-- 
Pedro Duque Vieira - https://www.pixelduke.com

From pmonks at gmail.com  Tue Oct 30 17:24:28 2018
From: pmonks at gmail.com (Peter Monks)
Date: Tue, 30 Oct 2018 10:24:28 -0700
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <CAAEud6YFuJzoyw0jTtJrDG1bXqDf3bM6u+4R1Sr2ff50+dKH3A@mail.gmail.com>
References: <CAN8FOXoJekdju-HmwbtL1ibJPcZS0CW39+B9NRHv2kTbL+D7fg@mail.gmail.com>
 <CAAEud6YFuJzoyw0jTtJrDG1bXqDf3bM6u+4R1Sr2ff50+dKH3A@mail.gmail.com>
Message-ID: <CAN8FOXq_0q5NNfLcq86PXQXOkMZ-RV-12NofcVafDzSX6p3OXQ@mail.gmail.com>

Apologies for the duplicate email - I have no idea how that happened.

Cheers,
Peter



On Tue, Oct 30, 2018 at 8:38 AM Pedro Duque Vieira <
pedro.duquevieira at gmail.com> wrote:

> Hi Peter,
>
> I've already answered you on this.
>
> Cheers,
>
> On Sun, Oct 28, 2018 at 6:29 PM Peter Monks <pmonks at gmail.com> wrote:
>
>> G'day!
>>
>> Just wondering whether OpenJFX's versions are always going to track to
>> specific JDK versions, or whether the plan is for OpenJFX versions to
>> decouple from JDK versions over time?
>>
>> From a downstream consumer's perspective, it would be ideal if OpenJFX
>> were
>> to decouple from the JDK, and provide some kind of version compatibility
>> matrix as new OpenJFX and JDK versions are released.  This is how most
>> Java
>> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
>> with that assumption.
>>
>> Thanks in advance for any light you're able to shed on this topic!
>>
>> Cheers,
>> Peter
>>
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>

From pedro.duquevieira at gmail.com  Tue Oct 30 17:33:03 2018
From: pedro.duquevieira at gmail.com (Pedro Duque Vieira)
Date: Tue, 30 Oct 2018 17:33:03 +0000
Subject: OpenJFX versions - will they always track to JDK versions?
In-Reply-To: <CAN8FOXq_0q5NNfLcq86PXQXOkMZ-RV-12NofcVafDzSX6p3OXQ@mail.gmail.com>
References: <CAN8FOXoJekdju-HmwbtL1ibJPcZS0CW39+B9NRHv2kTbL+D7fg@mail.gmail.com>
 <CAAEud6YFuJzoyw0jTtJrDG1bXqDf3bM6u+4R1Sr2ff50+dKH3A@mail.gmail.com>
 <CAN8FOXq_0q5NNfLcq86PXQXOkMZ-RV-12NofcVafDzSX6p3OXQ@mail.gmail.com>
Message-ID: <CAAEud6amAbG4SYhQ3H1Wy-BMJ9m5dny6XNz4ut0wJCVOZAgvgQ@mail.gmail.com>

No problem, Peter :)

On Tue, 30 Oct 2018 at 17:24, Peter Monks <pmonks at gmail.com> wrote:

> Apologies for the duplicate email - I have no idea how that happened.
>
> Cheers,
> Peter
>
>
>
> On Tue, Oct 30, 2018 at 8:38 AM Pedro Duque Vieira <
> pedro.duquevieira at gmail.com> wrote:
>
>> Hi Peter,
>>
>> I've already answered you on this.
>>
>> Cheers,
>>
>> On Sun, Oct 28, 2018 at 6:29 PM Peter Monks <pmonks at gmail.com> wrote:
>>
>>> G'day!
>>>
>>> Just wondering whether OpenJFX's versions are always going to track to
>>> specific JDK versions, or whether the plan is for OpenJFX versions to
>>> decouple from JDK versions over time?
>>>
>>> From a downstream consumer's perspective, it would be ideal if OpenJFX
>>> were
>>> to decouple from the JDK, and provide some kind of version compatibility
>>> matrix as new OpenJFX and JDK versions are released.  This is how most
>>> Java
>>> libraries do things, and a lot of Java tooling (e.g. Maven) is optimised
>>> with that assumption.
>>>
>>> Thanks in advance for any light you're able to shed on this topic!
>>>
>>> Cheers,
>>> Peter
>>>
>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
> --
Pedro Duque Vieira - https://www.pixelduke.com