Re: Enhancements for JavaFX 18

[Pedro Duque Vieira]

Hi again all,

I ended up not getting a follow up response.

Now that the Mac OS font rendering issue is taken care of, would it perhaps
be possible to look into this? Maybe it's just a quick fix as was the case
of Mac? That would be great if that's the case.

I believe this issue is very important as poor font rendering can
significantly impact the overall look of an app and Windows is still by far
the most used Operating System on Desktop.

Some tricks can improve the rendering on Windows
like: System.setProperty("prism.lcdtext", "false");
But on some cases (when you use bigger text, I think), even with that tweak
the quality of the font rendering can be poor.

Thanks again! Kind regards,


Virus-free.
www.avg.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Wed, Aug 11, 2021 at 4:17 PM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:

> .. on one client project I'm involved in, I ended up having to use a
> static image instead of rendering the text through JavaFX because of the
> difference in text rendering quality.
>
> On Wed, Aug 11, 2021 at 4:14 PM Pedro Duque Vieira <
> pedro.duquevie...@gmail.com> wrote:
>
>> OK thanks Phillip!
>>
>> Sorry, I might not have done the best job in reporting the issue
>> back then (it's been a while, it was in 2014) :-)
>>
>> I have an example of the exact same Segoe UI font. One is from Photoshop
>> using the text tool with a selected font and the other is from a JavaFX
>> using the same font. The difference is very noticeable.
>> Would you be interested in seeing the two pictures? If so, how can I
>> share them?
>>
>> Thanks again,
>>
>> On Tue, Aug 10, 2021 at 5:50 PM Philip Race 
>> wrote:
>>
>>> Well .. if you know you were the reporter, then it narrows down the JBS
>>> search from thousands to less than 10 :-)
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8092298
>>>
>>> Near as I can tell, that is an issue where we are comparing the FX use
>>> of DirectWrite with
>>> unknown usage and configuration of some Windows bundled apps and maybe
>>> we aren't
>>> even sure it is the same font ..  there was a lot of back and forth
>>> there.
>>>
>>> -phil.
>>>
>>> On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
>>>
>>> I've filed the bug a long time ago so I can't remember exactly the bug
>>> ID or the title I gave it.
>>>
>>> Do you want me to file a new one? Do you want me to attach sample images
>>> (I think you need to do some work around to attach images to a javafx bug
>>> report?)?
>>>
>>> Thanks Philip
>>>
>>> On Mon, Aug 9, 2021 at 4:06 PM Philip Race 
>>> wrote:
>>>
 That would be a separate piece of work.  I can't imagine much if any
 overlap.
 Is there a useful bug ID for what you are referring to ?
 The glyph images come from DirectWrite on Windows so I am not sure if
 there's something specific ..

 -phil.

 On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:

 Hi!

 @Phil Race  If you're going to tackle font
 rendering, would it also be possible to work on Windows font rendering? I
 find that Windows font rendering is generally much worse than Mac's.

 One example is, for instance, trying to render "Segoe UI" (the Windows
 default font) , or "Segoe UI Light"  font (or whatever variant) with a big
 font size. The font appears pixelated..

 Thanks,


> +1. It is something I intend to get to for 18.


 -phil.


 On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> > May I humbly suggest fixing font rendering color fringe issues on
> macOS


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



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


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

Re: Enhancements for JavaFX 18

[John Hendrikx]

I missed this question.

There are several external libaries available to help with these kinds 
of bindings.  There is EasyBind, ReactFX and an attempt of my own 
(https://github.com/hjohn/hs.jfx.eventstream).


They all have a different way of addressing this, but they do all have 
one thing in common: they all require that you wrap ObservableValues in 
their own extended variant of ObservableValue.  EasyBind has 
"MonadicObervableValue", ReactFX has "Val" and "Var" and my own attempt 
has "ValueStream".


Effectively this means you will get two types of properties in your 
JavaFX application, and you'll need to update standard properties like 
ObjectProperty to the type the framework provides to get the extra 
features. Interop between "old" and "new" code requires wrapping and 
sometimes unwrapping.


Integrating this into JavaFX's ObservableValue directly avoids all these 
wrappers and all the extra work that entails for the user of fluent 
bindings.


With this base in place, external libraries can provide streams and 
complicated mapping functions (ReactFX especially has an overabundance 
of features, most of which too niche to include into JavaFX directly).


That's not the only advantage however. When these are integrated, JavaFX 
internals can take advantage of them as well. Managing of cascading 
properties (usually done manually in JavaFX code, Bindings#select is not 
usually used) will be much cleaner and simpler.


Also the lazy bindings part of this MR can be used to avoid creating 
listeners for properties that aren't used themselves -- this allows for 
example Node to provide convience properties (like tree visibility) 
without having to  pre-emptively add listeners. This is not possible 
currently without consuming additional memory for every Node instance.


Finally, it also would serve as a type safe replacement for 
Bindings#select which is something that I think the team behind FX has 
been wanting to address for quite a while now.


--John

On 12/09/2021 01:38, Tom Schindl wrote:

I have not looked at the code yet but why does this have to be part of
OpenJFX and can not be implemented as an external library?

Tom

Am 05.08.21 um 00:25 schrieb John Hendrikx:

Perhaps:

Fluent bindings for ObservableValue
https://github.com/openjdk/jfx/pull/434

It was received well I think, and there was some interest from Nir
Lisker to work on a proposal.

--John

On 30/07/2021 14:56, Kevin Rushforth wrote:

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Abhinay Agarwal]

Hi,

I recently worked on removing a few left-over Traversal engine usage in 
ControlsFX [1].

It can be tricky, sometimes impossible, to get the traversal part right in a 
custom control which can be done using 2 lines if Traversal API was present [2].

This made me thinking if there is a scope of adding the Traversal engine API to 
JavaFX. Most of the heavy lifting was already done by Jonathan in JDK-8091673 
[3].

-- Abhinay

[1] https://github.com/controlsfx/controlsfx/pull/1395
[2] https://github.com/controlsfx/controlsfx/pull/1395/files#r712829957
[3] https://bugs.openjdk.java.net/browse/JDK-8091673

On 30/07/21 6:26 pm, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
enhancement requests for JavaFX 18. It's the summer, so there may be delays as 
some people are out at various times (including me), but I would like to get 
some of the outstanding enhancement requests moving over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary 
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to proceed)

* Undecorated interactive stage style (still in early discussion, but the 
concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev rather 
than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Tom Schindl]

I have not looked at the code yet but why does this have to be part of 
OpenJFX and can not be implemented as an external library?


Tom

Am 05.08.21 um 00:25 schrieb John Hendrikx:

Perhaps:

Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434

It was received well I think, and there was some interest from Nir 
Lisker to work on a proposal.


--John

On 30/07/2021 14:56, Kevin Rushforth wrote:

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin




--
Tom Schindl - CTO
BestSolution.at EDV Systemhaus GmbH
Salurner Straße 15, A-6020 Innsbruck
Phone: ++43 (0)512 935834
http://www.BestSolution.at - http://efxclipse.org

Re: Enhancements for JavaFX 18

[John Hendrikx]

I'm willing to invest the necessary time in this.

What should a concrete proposal consist of? Is there a format for this 
that I can follow (like 
https://gist.github.com/brcolow/26370db6cab0355186d4a1d13b30fc19 for 
example?)


Otherwise I can flesh out a small document with the Why, What, How of 
this addition, broken into several parts to keep each addition small but 
coherent with a larger whole.


My current proposal adds around 400 lines of code, which is about as 
small as I can get it while still offering something of value. The newly

introduced public API surface can be reduced a bit further.

A summary of the changes are:

ObservableValue interface

- 5 new methods with default implementations to support fluent mappings

- 2 new methods for registration of subscribers (could be removed from
  the public API for now).

ObjectBinding

- adds two new protected methods with trivial implementations
  in order to support the functionality needed by LazyObjectBinding

- functionality of class unaltered for any existing code, fully
  backwards compatible

Subcription interface

- new public interface with two methods (does not need to be part
  of the initial API, could be internal for now)

All the other code is just implementation and can be moved to internal 
packages which means that this change could be limited to introducing 
five new public methods and two protected ones.


If you can point me in the right direction, I'll work on a concrete 
proposal.


I also have a small Maven dependency with these changes as part of 
JavaFX (breaking module boundaries) that can serve as a preview of the 
feature if there is any interest.


--John

On 27/08/2021 18:58, Kevin Rushforth wrote:

This is a rather large addition to the properties API, but there seems
to be enough interest in it that it might be worth getting to the point
of a concrete proposal that we could discuss on the list.

I wouldn't expect it for JavaFX 18, since it will almost certainly take
longer than that. Which makes this a good time to remind folks that the
development model under the six month release cycle is such that
features go in when ready, rather than necessarily being tied to a
specific release.

-- Kevin


On 8/4/2021 3:25 PM, John Hendrikx wrote:

Perhaps:

Fluent bindings for ObservableValue
https://github.com/openjdk/jfx/pull/434

It was received well I think, and there was some interest from Nir
Lisker to work on a proposal.

--John

On 30/07/2021 14:56, Kevin Rushforth wrote:

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Nir Lisker]

I have updated the PR to use DoubleProperties for the pivots and added 2
BooleanProperties for the normalized coordinates toggle on Node. To the
Rotate/ScaleTransitions I added only the pivot properties that update those
of the node. It's a prototype, so ignore docs and other miscellania.
I also posted in a comment an interactive test app. It should be simple
enough to modify it for local testing.

I wasn't sure if the boolean properties should also be added to the
transitions. The rotation axis and pivot properties are mostly a
convenience since those can be updated on the node directly.

My greatest concern is the confusion that happens with transforms: I need
to be very careful when mixing those in since they use a different
coordinate system by default. In a way, if Node and the transitions find it
more natural to use normalized coordinates, shouldn't transforms find it
natural too? Not sure if this is inconvenient only for me.

On Sat, Aug 28, 2021 at 2:56 AM Nir Lisker  wrote:

> The problem I have with additional booleans is that they are not
> reflected in the transitions, and to a lesser extent in the transforms.
>
> I'm going to have to write an implementation and test it out to know how
> well this works and how much trouble it really saves.
>
> And while we could use NaN as an out of band value meaning "computed",
>> that still runs into the problem of allowing for the odd case where X is
>> computed and Y is specified.
>
>
> I don't see this as a problem. Each direction is independent. The bigger
> problem I see is the surprise factor of NaN as a computed value.
>
> On Tue, Aug 24, 2021 at 6:16 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com> wrote:
>
>> I definitely don't like having a "magic" initial value that can't be
>> reset, so that won't work. And while we could use NaN as an out of band
>> value meaning "computed", that still runs into the problem of allowing for
>> the odd case where X is computed and Y is specified.
>>
>> If we do go with the idea of allowing the coordinates to be a percentage
>> of the bounding box, with 0.5 as the default, then we could be informed by
>> what ImagePattern does. It defines a "proportional" property as follows:
>>
>> "a boolean that indicates whether start and end locations are
>> proportional or absolute. If this flag is true, the two end points are
>> defined in a coordinate space where coordinates in the range [0..1] are
>> scaled to map onto the bounds of the shape that the pattern fills. If this
>> flag is false, then the coordinates are specified in the local coordinate
>> system of the node."
>>
>> That's basically what we are doing if we go with Michael's idea. So if we
>> do this, the two boolean properties could be named something like
>> scalePivotProportional and rotatePivotProportional, with a default of true.
>>
>> What do you think?
>>
>> -- Kevin
>>
>>
>>
>> On 8/23/2021 7:25 PM, Michael Strauß wrote:
>>
>> I think normalized coordinates are a very natural fit for the
>> definition of a pivot point, which is why the current default value is
>> an implicitly-specified normalized coordinate. Adding general-purpose
>> coordinate transformations here feels like bringing a sledgehammer to
>> crack a nut.
>>
>> Having a property with an automagically updated "initial" value is
>> quite non-standard behavior for properties. It would appear as if the
>> property was bound, yet there's no binding. That's markedly different
>> from a Transition's 'from' and 'to' properties, which are standard
>> properties with normal behavior. A running transition doesn't bind to
>> those properties, it uses a snapshot of their values when the
>> transition starts.
>>
>>
>> On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker  
>>  wrote:
>>
>> Now I understand what you meant. However, the concept of normalized 
>> coordinates does not appear anywhere in JavaFX (at least not in these 
>> contexts). I still think that coordinate transformations should be handled 
>> via dedicated means, like coordinate system transformations are. Maybe when 
>> we work on mapped bindings (I forgot that I need to review that) this pain 
>> point will be alleviated.
>>
>> Kevin, what if we only set the initial value of the pivot (doesn't matter 
>> what the implementation detail is) to the center of the node for backwards 
>> compatibility, but if the developer changes it to a custom value then it's 
>> on them to compute the value again if they want to go back? The default 
>> behavior remains.
>> Another relevant point is that Transitions do something similar with their 
>> from_,  to_ and by_ methods. They start with Double.NaN to signal that the 
>> value should be ignored. While the developer can reset the value to NaN, it 
>> is not something that is likely to happen during, say, an interpolation or 
>> as a result of a binding.
>>
>>
>>
>>

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

I'm on board with this, and agree that this would be a good one to move 
forward.


-- Kevin


On 9/7/2021 3:49 PM, John Neffenger wrote:

On 8/19/21 1:27 PM, Kevin Rushforth wrote:
Those enhancements that have reached general consensus, are far 
enough along in the process that we have a good idea how much they 
will "cost", and have a willing contributor and sponsor (for 
contributors who are not Committers), are more likely to make JavaFX 18.


I'd like to make a pitch for integrating the reproducible build support:

8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
https://github.com/openjdk/jfx/pull/446

It's not as glamorous as the user interface changes that have been 
suggested. I think the change is inevitable, though, so it would be 
great to have it integrated while I can still remember what I did. 
I've tested it in two separate rounds of tests on all three platforms, 
and it has been approved by two reviewers.


The JDK is also doing this work, driven mostly by Magnus Ihse Bursie 
at Oracle in the OpenJDK Build Infrastructure Group. He calls it "a 
low-effort, background-style project to make the build of OpenJDK 
itself building reproducible."


For the original motivation, see the following closed pull request 
that is now included in the one linked above:


8238650: Allow to override buildDate with SOURCE_DATE_EPOCH
https://github.com/openjdk/jfx/pull/422

Thanks,
John

Re: Enhancements for JavaFX 18

[John Neffenger]

On 8/19/21 1:27 PM, Kevin Rushforth wrote:
Those enhancements that have reached general consensus, are far enough 
along in the process that we have a good idea how much they will "cost", 
and have a willing contributor and sponsor (for contributors who are not 
Committers), are more likely to make JavaFX 18.


I'd like to make a pitch for integrating the reproducible build support:

8264449: Enable reproducible builds with SOURCE_DATE_EPOCH
https://github.com/openjdk/jfx/pull/446

It's not as glamorous as the user interface changes that have been 
suggested. I think the change is inevitable, though, so it would be 
great to have it integrated while I can still remember what I did. I've 
tested it in two separate rounds of tests on all three platforms, and it 
has been approved by two reviewers.


The JDK is also doing this work, driven mostly by Magnus Ihse Bursie at 
Oracle in the OpenJDK Build Infrastructure Group. He calls it "a 
low-effort, background-style project to make the build of OpenJDK itself 
building reproducible."


For the original motivation, see the following closed pull request that 
is now included in the one linked above:


8238650: Allow to override buildDate with SOURCE_DATE_EPOCH
https://github.com/openjdk/jfx/pull/422

Thanks,
John

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Nir Lisker]

The problem I have with additional booleans is that they are not
reflected in the transitions, and to a lesser extent in the transforms.

I'm going to have to write an implementation and test it out to know how
well this works and how much trouble it really saves.

And while we could use NaN as an out of band value meaning "computed", that
> still runs into the problem of allowing for the odd case where X is
> computed and Y is specified.


I don't see this as a problem. Each direction is independent. The bigger
problem I see is the surprise factor of NaN as a computed value.

On Tue, Aug 24, 2021 at 6:16 PM Kevin Rushforth 
wrote:

> I definitely don't like having a "magic" initial value that can't be
> reset, so that won't work. And while we could use NaN as an out of band
> value meaning "computed", that still runs into the problem of allowing for
> the odd case where X is computed and Y is specified.
>
> If we do go with the idea of allowing the coordinates to be a percentage
> of the bounding box, with 0.5 as the default, then we could be informed by
> what ImagePattern does. It defines a "proportional" property as follows:
>
> "a boolean that indicates whether start and end locations are proportional
> or absolute. If this flag is true, the two end points are defined in a
> coordinate space where coordinates in the range [0..1] are scaled to map
> onto the bounds of the shape that the pattern fills. If this flag is false,
> then the coordinates are specified in the local coordinate system of the
> node."
>
> That's basically what we are doing if we go with Michael's idea. So if we
> do this, the two boolean properties could be named something like
> scalePivotProportional and rotatePivotProportional, with a default of true.
>
> What do you think?
>
> -- Kevin
>
>
>
> On 8/23/2021 7:25 PM, Michael Strauß wrote:
>
> I think normalized coordinates are a very natural fit for the
> definition of a pivot point, which is why the current default value is
> an implicitly-specified normalized coordinate. Adding general-purpose
> coordinate transformations here feels like bringing a sledgehammer to
> crack a nut.
>
> Having a property with an automagically updated "initial" value is
> quite non-standard behavior for properties. It would appear as if the
> property was bound, yet there's no binding. That's markedly different
> from a Transition's 'from' and 'to' properties, which are standard
> properties with normal behavior. A running transition doesn't bind to
> those properties, it uses a snapshot of their values when the
> transition starts.
>
>
> On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker  
>  wrote:
>
> Now I understand what you meant. However, the concept of normalized 
> coordinates does not appear anywhere in JavaFX (at least not in these 
> contexts). I still think that coordinate transformations should be handled 
> via dedicated means, like coordinate system transformations are. Maybe when 
> we work on mapped bindings (I forgot that I need to review that) this pain 
> point will be alleviated.
>
> Kevin, what if we only set the initial value of the pivot (doesn't matter 
> what the implementation detail is) to the center of the node for backwards 
> compatibility, but if the developer changes it to a custom value then it's on 
> them to compute the value again if they want to go back? The default behavior 
> remains.
> Another relevant point is that Transitions do something similar with their 
> from_,  to_ and by_ methods. They start with Double.NaN to signal that the 
> value should be ignored. While the developer can reset the value to NaN, it 
> is not something that is likely to happen during, say, an interpolation or as 
> a result of a binding.
>
>
>
>

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

On 8/27/2021 2:47 PM, Jeanette Winzenburg wrote:


Zitat von Kevin Rushforth :

Yes, it would be great to finally solve this one. It would need 
someone who is willing and able to to drive it, though.


-- Kevin


Well, I think myself being both - with a little help of my friends ;)


Excellent! I was hoping you might volunteer for this, but didn't want to 
presume.


-- Kevin




-- Jeanette



On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost - 
solved by an enhancement to the editing api on virtualized controls


-- Jeanette

Zitat von Kevin Rushforth :

Now that JavaFX 17 is in RDP2, we can turn more attention to bug 
fixes and enhancement requests for JavaFX 18. It's the summer, so 
there may be delays as some people are out at various times 
(including me), but I would like to get some of the outstanding 
enhancement requests moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how 
to proceed)


* Undecorated interactive stage style (still in early discussion, 
but the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: Enhancements for JavaFX 18

[Jeanette Winzenburg]

Zitat von Kevin Rushforth :

Yes, it would be great to finally solve this one. It would need  
someone who is willing and able to to drive it, though.


-- Kevin


Well, I think myself being both - with a little help of my friends ;)

-- Jeanette



On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost -  
solved by an enhancement to the editing api on virtualized controls


-- Jeanette

Zitat von Kevin Rushforth :

Now that JavaFX 17 is in RDP2, we can turn more attention to bug  
fixes and enhancement requests for JavaFX 18. It's the summer, so  
there may be delays as some people are out at various times  
(including me), but I would like to get some of the outstanding  
enhancement requests moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the  
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how  
to proceed)


* Undecorated interactive stage style (still in early discussion,  
but the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on  
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: [External] : Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Btw, I filed the following Enhancement for deprecating GTK 2 for removal:

https://bugs.openjdk.java.net/browse/JDK-8273089

And I dug up the bug I had previously filed to remove the unused applet 
implementation code:


https://bugs.openjdk.java.net/browse/JDK-8201538

-- Kevin


On 8/27/2021 11:39 AM, Kevin Rushforth wrote:
Thanks. As a follow-on though, it seems possible that not having GTK 2 
support might help in our efforts to support GTK 4 or Wayland, but 
maybe that's wishful thinking on my part.


-- Kevin



On 8/27/2021 11:27 AM, Johan Vos wrote:
I agree with both suggestions (also with the Wayland one, but that 
indeed belongs in a different thread -- I'm working on that one 
locally).


- Johan


On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Definitely agree with the first one. Getting rid of the vestigial
applet
code in the implementation would be good cleanup.

As for the second, I like the idea of deprecating the gtk2
support "for
removal" (it's not API, but conceptually it similar). Since gtk2
is no
longer supported by any Linux distro I don't see any reason to keep
maintaining gtk2. The path for doing this would be to print a
"deprecated for removal" warning message when the gtk2 library it is
loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20.
I'll
file an RFE for the first part (the deprecation for removal).

Wayland has already been discussed in another thread.

-- Kevin



On 8/9/2021 2:39 PM, Thiago Milczarek Sayão wrote:
> I would add:
>
> * Remove deprecated applets/web start code;
> * Mark for removal or remove Gtk2 support . Gtk3 has been
around for
> 10 years.
> * Work to support wayland, as it will probably be the default
in the
> future.
>
> - Thiago.
>
>
> Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth
> mailto:kevin.rushfo...@oracle.com>
>> escreveu:
>
>     Now that JavaFX 17 is in RDP2, we can turn more attention
to bug
>     fixes
>     and enhancement requests for JavaFX 18. It's the summer, so
there
>     may be
>     delays as some people are out at various times (including
me), but I
>     would like to get some of the outstanding enhancement
requests moving
>     over the next few weeks.
>
>     Specifically, I'd like to see the following proceed:
>
>     * Transparent backgrounds in WebView
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8090547

>     >
>     PR: https://github.com/openjdk/jfx/pull/563


>   
 
>
>
>     * Add DirectionalLight
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8234921

>     >
>     PR: https://github.com/openjdk/jfx/pull/548


>   
 
>
>
>     * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225

>     >
>     PR: https://github.com/openjdk/jfx/pull/475


>   
 

Re: [External] : Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Thanks. As a follow-on though, it seems possible that not having GTK 2 
support might help in our efforts to support GTK 4 or Wayland, but maybe 
that's wishful thinking on my part.


-- Kevin



On 8/27/2021 11:27 AM, Johan Vos wrote:
I agree with both suggestions (also with the Wayland one, but that 
indeed belongs in a different thread -- I'm working on that one locally).


- Johan


On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Definitely agree with the first one. Getting rid of the vestigial
applet
code in the implementation would be good cleanup.

As for the second, I like the idea of deprecating the gtk2 support
"for
removal" (it's not API, but conceptually it similar). Since gtk2
is no
longer supported by any Linux distro I don't see any reason to keep
maintaining gtk2. The path for doing this would be to print a
"deprecated for removal" warning message when the gtk2 library it is
loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll
file an RFE for the first part (the deprecation for removal).

Wayland has already been discussed in another thread.

-- Kevin



On 8/9/2021 2:39 PM, Thiago Milczarek Sayão wrote:
> I would add:
>
> * Remove deprecated applets/web start code;
> * Mark for removal or remove Gtk2 support . Gtk3 has been around
for
> 10 years.
> * Work to support wayland, as it will probably be the default in
the
> future.
>
> - Thiago.
>
>
> Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth
> mailto:kevin.rushfo...@oracle.com>
>> escreveu:
>
>     Now that JavaFX 17 is in RDP2, we can turn more attention to bug
>     fixes
>     and enhancement requests for JavaFX 18. It's the summer, so
there
>     may be
>     delays as some people are out at various times (including
me), but I
>     would like to get some of the outstanding enhancement
requests moving
>     over the next few weeks.
>
>     Specifically, I'd like to see the following proceed:
>
>     * Transparent backgrounds in WebView
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8090547

>     >
>     PR: https://github.com/openjdk/jfx/pull/563


>   
 
>
>
>     * Add DirectionalLight
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8234921

>     >
>     PR: https://github.com/openjdk/jfx/pull/548


>   
 
>
>
>     * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225

>     >
>     PR: https://github.com/openjdk/jfx/pull/475


>   
 
>
>
>     * Improve property system to facilitate correct usage (minus the
>     binary
>     incompatible API change)
>     JBS: https://bugs.openjdk.java.net/browse/JDK-8268642

Re: [External] : Re: Enhancements for JavaFX 18

[Johan Vos]

I agree with both suggestions (also with the Wayland one, but that indeed
belongs in a different thread -- I'm working on that one locally).

- Johan


On Fri, Aug 27, 2021 at 7:07 PM Kevin Rushforth 
wrote:

> Definitely agree with the first one. Getting rid of the vestigial applet
> code in the implementation would be good cleanup.
>
> As for the second, I like the idea of deprecating the gtk2 support "for
> removal" (it's not API, but conceptually it similar). Since gtk2 is no
> longer supported by any Linux distro I don't see any reason to keep
> maintaining gtk2. The path for doing this would be to print a
> "deprecated for removal" warning message when the gtk2 library it is
> loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll
> file an RFE for the first part (the deprecation for removal).
>
> Wayland has already been discussed in another thread.
>
> -- Kevin
>
>
>
> On 8/9/2021 2:39 PM, Thiago Milczarek Sayão wrote:
> > I would add:
> >
> > * Remove deprecated applets/web start code;
> > * Mark for removal or remove Gtk2 support . Gtk3 has been around for
> > 10 years.
> > * Work to support wayland, as it will probably be the default in the
> > future.
> >
> > - Thiago.
> >
> >
> > Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth
> > mailto:kevin.rushfo...@oracle.com>>
> escreveu:
> >
> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug
> > fixes
> > and enhancement requests for JavaFX 18. It's the summer, so there
> > may be
> > delays as some people are out at various times (including me), but I
> > would like to get some of the outstanding enhancement requests moving
> > over the next few weeks.
> >
> > Specifically, I'd like to see the following proceed:
> >
> > * Transparent backgrounds in WebView
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> > 
> > PR: https://github.com/openjdk/jfx/pull/563
> > <
> https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/563__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgtBVjHVs$
> >
> >
> > * Add DirectionalLight
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> > 
> > PR: https://github.com/openjdk/jfx/pull/548
> > <
> https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/548__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgiWYnbRD$
> >
> >
> > * CSS pseudoclasses :focus-visible and :focus-within
> > https://bugs.openjdk.java.net/browse/JDK-8268225
> > 
> > PR: https://github.com/openjdk/jfx/pull/475
> > <
> https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/475__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKgreYERKS$
> >
> >
> > * Improve property system to facilitate correct usage (minus the
> > binary
> > incompatible API change)
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> > 
> > PR: https://github.com/openjdk/jfx/pull/590
> > <
> https://urldefense.com/v3/__https://github.com/openjdk/jfx/pull/590__;!!ACWV5N9M2RV99hQ!e1mwjFFLu6Juw0WyL7BhDn_RV__AjpAhmev0ikZPsBmfhwAX0G_0_AbSOeKKggImJHfK$
> >
> > (Draft)
> >
> > And maybe the following:
> >
> > * Add CSS themes as a first-class concept (need a consensus on how to
> > proceed)
> >
> > * Undecorated interactive stage style (still in early discussion, but
> > the concept looks interesting and useful)
> >
> > There are probably others I'm forgetting.
> >
> > Each of the above should be discussed in their own thread on
> > openjfx-dev
> > rather than a reply to this thread.
> >
> > -- Kevin
> >
> >
>
>

Re: [External] : Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Definitely agree with the first one. Getting rid of the vestigial applet 
code in the implementation would be good cleanup.


As for the second, I like the idea of deprecating the gtk2 support "for 
removal" (it's not API, but conceptually it similar). Since gtk2 is no 
longer supported by any Linux distro I don't see any reason to keep 
maintaining gtk2. The path for doing this would be to print a 
"deprecated for removal" warning message when the gtk2 library it is 
loaded in JavaFX 18. We could then remove it in JavaFX 19 or 20. I'll 
file an RFE for the first part (the deprecation for removal).


Wayland has already been discussed in another thread.

-- Kevin



On 8/9/2021 2:39 PM, Thiago Milczarek Sayão wrote:

I would add:

* Remove deprecated applets/web start code;
* Mark for removal or remove Gtk2 support . Gtk3 has been around for 
10 years.
* Work to support wayland, as it will probably be the default in the 
future.


- Thiago.


Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> escreveu:


Now that JavaFX 17 is in RDP2, we can turn more attention to bug
fixes
and enhancement requests for JavaFX 18. It's the summer, so there
may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547

PR: https://github.com/openjdk/jfx/pull/563



* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921

PR: https://github.com/openjdk/jfx/pull/548



* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225

PR: https://github.com/openjdk/jfx/pull/475



* Improve property system to facilitate correct usage (minus the
binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642

PR: https://github.com/openjdk/jfx/pull/590


(Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on
openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

That's an interesting idea, although it's not on our radar. This might 
be hard to do in a platform-independent way. It's not likely something 
we would do ourselves, so it would need an owner and we would need to 
discuss


-- Kevin


On 8/11/2021 1:10 PM, Dirk Lemmermann wrote:

Frosted glas / blurred background for stages!


Am 11.08.2021 um 22:07 schrieb Thiago Milczarek Sayão :

Hi,

One feature I will probably submit is touch events on Linux.

Cheers.

Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

We aren't currently planning to do this any time soon, although there 
does seem to be plenty of interest in the system tray support.


-- Kevin


On 8/4/2021 7:47 AM, Scott Palmer wrote:

+1 to that.

I would also like to see some progress with system tray support and microphone 
& webcam access.

Scott


On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg  wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost - solved by 
an enhancement to the editing api on virtualized controls

-- Jeanette

Zitat von Kevin Rushforth :


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
enhancement requests for JavaFX 18. It's the summer, so there may be delays as 
some people are out at various times (including me), but I would like to get 
some of the outstanding enhancement requests moving over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary 
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to proceed)

* Undecorated interactive stage style (still in early discussion, but the 
concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev rather 
than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Yes, it would be great to finally solve this one. It would need someone 
who is willing and able to to drive it, though.


-- Kevin


On 8/4/2021 2:58 AM, Jeanette Winzenburg wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost - 
solved by an enhancement to the editing api on virtualized controls


-- Jeanette

Zitat von Kevin Rushforth :

Now that JavaFX 17 is in RDP2, we can turn more attention to bug 
fixes and enhancement requests for JavaFX 18. It's the summer, so 
there may be delays as some people are out at various times 
(including me), but I would like to get some of the outstanding 
enhancement requests moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

This is a rather large addition to the properties API, but there seems 
to be enough interest in it that it might be worth getting to the point 
of a concrete proposal that we could discuss on the list.


I wouldn't expect it for JavaFX 18, since it will almost certainly take 
longer than that. Which makes this a good time to remind folks that the 
development model under the six month release cycle is such that 
features go in when ready, rather than necessarily being tied to a 
specific release.


-- Kevin


On 8/4/2021 3:25 PM, John Hendrikx wrote:

Perhaps:

Fluent bindings for ObservableValue 
https://github.com/openjdk/jfx/pull/434


It was received well I think, and there was some interest from Nir 
Lisker to work on a proposal.


--John

On 30/07/2021 14:56, Kevin Rushforth wrote:

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

As more of a general comment (not just to you), I wasn't really asking 
for a laundry list of bugs or enhancements that people would like to see 
fixed. Rather, I was thinking about the things that were already "in 
flight" or "on the radar", so we could see about moving some of them 
forward.


Having said that, the first step for any of the bugs on yours or anyone 
else's wish list would be to files a bug in JBS with a reproducible test 
case. Some of the ones listed below already have a bug filed, but most 
do not.


-- Kevin


On 8/4/2021 10:05 AM, Ty Young wrote:

You want a list of bugs that could be fixed? Today's your lucky day!


* Resizing a JavaFX window under Linux (still) causes graphical 
glitches, needing -Dprism.forceUploadingPainter=true or, IIRC, 
software rendering to "fix".



* Resizing ALSO causes graphical glitching on the bottom and right 
sides on both Windows AND Linux.



* Resizing an app with a TableView in view results in the TableView's 
integrated scrollbars flickering in and out of existence when there is 
plenty of space left. The less UI content there is, the less this is 
likely to happen - but it absolutely does happen with *just* a 
TableView as the root node, you gotta play with it.



* Resizing the application from the left causes UI jitter.


* JavaFX in general seems to have trouble keeping up with user 
resizing. Rapidly resizing an application with a DividerPane(TreeView 
left, content right) results in inconsistent positioning than if it 
was done slowly, in the very least.



* Alt tabbing with a UI component being selected(Slider thumb, 
scrollbar) results in that component's color being stuck in whatever 
color is the CSS selected state.



* You can middle and right click drag a slider thumb and scroll bars, 
which does not trigger a CSS state change, which is not consistent 
with MenuBar items.



* JavaFX does not seem to calculate the size of a GridPane or TilePane 
with elements correctly. This results in content in ScrollPanes that 
is clearly larger in height than the viewport but ScrollPane does not 
show its scrollbars - only mouse wheel works without forcing the 
scrollbars to always show or transition state bugs when putting a 
GridPane/TilePane inside a TitlePane(or maybe it's TilePane -> 
TitlePane -> TilePane that's the issue? No clue.)



* XY Chart data that is off screen (-1, -1) has lines drawn to them 
despite being... off screen. Bug or feature?



* Setting the Y axis side to Side.RIGHT causes a white space with 
custom CSS: https://imgur.com/a/4P1Oj1Q.



Might be missing some.


A few features, while I'm here:


* API property to force a TableView's height to be the exact amount 
needed to display its headers and all its rows.



* API to disable TableView's scrollbars completely.


* A late "showing" property for when the application has been shown to 
the user and all first viewing UI components have had their sizes 
calculated and are being displayed, if it doesn't exist already and 
I'm completely blind.



On 7/30/21 7:56 AM, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug 
fixes and enhancement requests for JavaFX 18. It's the summer, so 
there may be delays as some people are out at various times 
(including me), but I would like to get some of the outstanding 
enhancement requests moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Kevin Rushforth]

I definitely don't like having a "magic" initial value that can't be 
reset, so that won't work. And while we could use NaN as an out of band 
value meaning "computed", that still runs into the problem of allowing 
for the odd case where X is computed and Y is specified.


If we do go with the idea of allowing the coordinates to be a percentage 
of the bounding box, with 0.5 as the default, then we could be informed 
by what ImagePattern does. It defines a "proportional" property as follows:


"a boolean that indicates whether start and end locations are 
proportional or absolute. If this flag is true, the two end points are 
defined in a coordinate space where coordinates in the range |[0..1]| 
are scaled to map onto the bounds of the shape that the pattern fills. 
If this flag is false, then the coordinates are specified in the local 
coordinate system of the node."


That's basically what we are doing if we go with Michael's idea. So if 
we do this, the two boolean properties could be named something like 
scalePivotProportional and rotatePivotProportional, with a default of true.


What do you think?

-- Kevin



On 8/23/2021 7:25 PM, Michael Strauß wrote:

I think normalized coordinates are a very natural fit for the
definition of a pivot point, which is why the current default value is
an implicitly-specified normalized coordinate. Adding general-purpose
coordinate transformations here feels like bringing a sledgehammer to
crack a nut.

Having a property with an automagically updated "initial" value is
quite non-standard behavior for properties. It would appear as if the
property was bound, yet there's no binding. That's markedly different
from a Transition's 'from' and 'to' properties, which are standard
properties with normal behavior. A running transition doesn't bind to
those properties, it uses a snapshot of their values when the
transition starts.


On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker  wrote:

Now I understand what you meant. However, the concept of normalized coordinates 
does not appear anywhere in JavaFX (at least not in these contexts). I still 
think that coordinate transformations should be handled via dedicated means, 
like coordinate system transformations are. Maybe when we work on mapped 
bindings (I forgot that I need to review that) this pain point will be 
alleviated.

Kevin, what if we only set the initial value of the pivot (doesn't matter what 
the implementation detail is) to the center of the node for backwards 
compatibility, but if the developer changes it to a custom value then it's on 
them to compute the value again if they want to go back? The default behavior 
remains.
Another relevant point is that Transitions do something similar with their 
from_,  to_ and by_ methods. They start with Double.NaN to signal that the 
value should be ignored. While the developer can reset the value to NaN, it is 
not something that is likely to happen during, say, an interpolation or as a 
result of a binding.

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Michael Strauß]

I think normalized coordinates are a very natural fit for the
definition of a pivot point, which is why the current default value is
an implicitly-specified normalized coordinate. Adding general-purpose
coordinate transformations here feels like bringing a sledgehammer to
crack a nut.

Having a property with an automagically updated "initial" value is
quite non-standard behavior for properties. It would appear as if the
property was bound, yet there's no binding. That's markedly different
from a Transition's 'from' and 'to' properties, which are standard
properties with normal behavior. A running transition doesn't bind to
those properties, it uses a snapshot of their values when the
transition starts.


On Sun, Aug 22, 2021 at 9:55 PM Nir Lisker  wrote:
>
> Now I understand what you meant. However, the concept of normalized 
> coordinates does not appear anywhere in JavaFX (at least not in these 
> contexts). I still think that coordinate transformations should be handled 
> via dedicated means, like coordinate system transformations are. Maybe when 
> we work on mapped bindings (I forgot that I need to review that) this pain 
> point will be alleviated.
>
> Kevin, what if we only set the initial value of the pivot (doesn't matter 
> what the implementation detail is) to the center of the node for backwards 
> compatibility, but if the developer changes it to a custom value then it's on 
> them to compute the value again if they want to go back? The default behavior 
> remains.
> Another relevant point is that Transitions do something similar with their 
> from_,  to_ and by_ methods. They start with Double.NaN to signal that the 
> value should be ignored. While the developer can reset the value to NaN, it 
> is not something that is likely to happen during, say, an interpolation or as 
> a result of a binding.
>

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Nir Lisker]

Now I understand what you meant. However, the concept of normalized
coordinates does not appear anywhere in JavaFX (at least not in these
contexts). I still think that coordinate transformations should be handled
via dedicated means, like coordinate system transformations are. Maybe when
we work on mapped bindings (I forgot that I need to review that) this pain
point will be alleviated.

Kevin, what if we only set the initial value of the pivot (doesn't matter
what the implementation detail is) to the center of the node for backwards
compatibility, but if the developer changes it to a custom value then it's
on them to compute the value again if they want to go back? The default
behavior remains.
Another relevant point is that Transitions do something similar with their
from_,  to_ and by_ methods. They start with Double.NaN to signal that the
value should be ignored. While the developer can reset the value to NaN, it
is not something that is likely to happen during, say, an interpolation or
as a result of a binding.

On Sun, Aug 22, 2021 at 7:14 PM Michael Strauß 
wrote:

> Yes, calling it „relativePivot“ might have been a poor naming choice. The
> purpose was to toggle between normalized/non-normalized coordinates,
> effectively allowing developers to customize the „computed pivot“.
>
> So instead of ignoring the specified X/Y/Z pivot coordinates and computing
> the center of the node, the „relativePivot“ toggle would instead interpret
> the specified values as normalized coordinates relative to the node.
>
>
> On Sunday, August 22, 2021, Nir Lisker  wrote:
>
>> The special case of "center of the node" (the computed pivot) is the
>> current behavior, and it needs to be preserved for backwards compatibility.
>> This is why we were discussing the out of band values issues to begin with.
>>
>> Reading the rest of what you wrote makes me think I didn't
>> understand your terminology. Does the "relativePivot" switch between
>> normalized coordinates and non-normalized coordinates, both in the
>> coordinate system of the node?
>>
>> On Sat, Aug 21, 2021 at 11:23 PM Michael Strauß 
>> wrote:
>>
>>> I think that „computed pivot“ is both an unnecessary terminology, and
>>> really only one special case of a pivot coordinate in unit space where 0/0
>>> is the top-left corner of the node, and 1/1 is the bottom-right corner of
>>> the node (which is what I referred to as „relative“ coordinates).
>>>
>>> Quite often, it can be more useful to define pivots in unit space,
>>> because it’s an easy answer to a problem like „rotate the node 45 degrees
>>> around its top-left corner“. Special-casing the 0.5/0.5 unit coordinate and
>>> not allowing any other feels like a lackluster API, and increases the
>>> effort for developers to solve a very common problem.
>>>
>>> From an implementation perspective, there’s not much of a difference in
>>> development and maintenance cost. The projection from unit space to pixel
>>> space needs to happen anyway (that’s the „computed“ part in „computed
>>> pivot“), and allowing any coordinate rather than the 0.5/0.5 midpoint is
>>> only a single multiplication away.
>>>
>>>
>>>
>>>
>>> On Saturday, August 21, 2021, Kevin Rushforth <
>>> kevin.rushfo...@oracle.com> wrote:
>>>
 I didn't page in enough of the discussion before. I remember now why we
 need separate pivots for rotate and scale, so thank you for reminding me.
 Btw, I don't think that necessarily means we need a separate switch for
 whether to use computed vs explicit for each (but that would be a
 possibility).

 I agree with the points raised about relative versus "absolute". While
 it is an intriguing idea, it probably doesn't fit here.

 While it is a clever idea to use an ObjectProperty rather than
 a DoubleProperty so we have an out of band value to use for "compute this"
 I don't think that we should do it that way for a few reasons. First, it's
 inconsistent with all other number based properties, in a way that could
 cause usability issues (e.g., you couldn't just pass pivotXProperty()
 directly to a method that expects a DoubleProperty). Second, I don't like
 the implications of having separate "auto-compute" flags on each of X, Y,
 and Z. Third, is the documentation issue you mentioned.

 So amending my earlier answers to the three questions:

 1. A single boolean property for whether to use a compute pivot (the
 default) vs an explicit pivot; this would apply to both rotate and scale
 pivots.
 2. 3 separate doubles (using DoubleProperty).
 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties.

 -- Kevin

 On 8/21/2021 6:19 AM, Nir Lisker wrote:

 In the previous time this was discussed I suggested a 3rd option, in
 addition to ObjectProperty and 3 DoubleProperties, which is 3
 ObjectPropertys.

 Advantages:
 1. Allows using null to remove any specified user 

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Michael Strauß]

Yes, calling it „relativePivot“ might have been a poor naming choice. The
purpose was to toggle between normalized/non-normalized coordinates,
effectively allowing developers to customize the „computed pivot“.

So instead of ignoring the specified X/Y/Z pivot coordinates and computing
the center of the node, the „relativePivot“ toggle would instead interpret
the specified values as normalized coordinates relative to the node.


On Sunday, August 22, 2021, Nir Lisker  wrote:

> The special case of "center of the node" (the computed pivot) is the
> current behavior, and it needs to be preserved for backwards compatibility.
> This is why we were discussing the out of band values issues to begin with.
>
> Reading the rest of what you wrote makes me think I didn't understand your
> terminology. Does the "relativePivot" switch between normalized coordinates
> and non-normalized coordinates, both in the coordinate system of the node?
>
> On Sat, Aug 21, 2021 at 11:23 PM Michael Strauß 
> wrote:
>
>> I think that „computed pivot“ is both an unnecessary terminology, and
>> really only one special case of a pivot coordinate in unit space where 0/0
>> is the top-left corner of the node, and 1/1 is the bottom-right corner of
>> the node (which is what I referred to as „relative“ coordinates).
>>
>> Quite often, it can be more useful to define pivots in unit space,
>> because it’s an easy answer to a problem like „rotate the node 45 degrees
>> around its top-left corner“. Special-casing the 0.5/0.5 unit coordinate and
>> not allowing any other feels like a lackluster API, and increases the
>> effort for developers to solve a very common problem.
>>
>> From an implementation perspective, there’s not much of a difference in
>> development and maintenance cost. The projection from unit space to pixel
>> space needs to happen anyway (that’s the „computed“ part in „computed
>> pivot“), and allowing any coordinate rather than the 0.5/0.5 midpoint is
>> only a single multiplication away.
>>
>>
>>
>>
>> On Saturday, August 21, 2021, Kevin Rushforth 
>> wrote:
>>
>>> I didn't page in enough of the discussion before. I remember now why we
>>> need separate pivots for rotate and scale, so thank you for reminding me.
>>> Btw, I don't think that necessarily means we need a separate switch for
>>> whether to use computed vs explicit for each (but that would be a
>>> possibility).
>>>
>>> I agree with the points raised about relative versus "absolute". While
>>> it is an intriguing idea, it probably doesn't fit here.
>>>
>>> While it is a clever idea to use an ObjectProperty rather than a
>>> DoubleProperty so we have an out of band value to use for "compute this" I
>>> don't think that we should do it that way for a few reasons. First, it's
>>> inconsistent with all other number based properties, in a way that could
>>> cause usability issues (e.g., you couldn't just pass pivotXProperty()
>>> directly to a method that expects a DoubleProperty). Second, I don't like
>>> the implications of having separate "auto-compute" flags on each of X, Y,
>>> and Z. Third, is the documentation issue you mentioned.
>>>
>>> So amending my earlier answers to the three questions:
>>>
>>> 1. A single boolean property for whether to use a compute pivot (the
>>> default) vs an explicit pivot; this would apply to both rotate and scale
>>> pivots.
>>> 2. 3 separate doubles (using DoubleProperty).
>>> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties.
>>>
>>> -- Kevin
>>>
>>> On 8/21/2021 6:19 AM, Nir Lisker wrote:
>>>
>>> In the previous time this was discussed I suggested a 3rd option, in
>>> addition to ObjectProperty and 3 DoubleProperties, which is 3
>>> ObjectPropertys.
>>>
>>> Advantages:
>>> 1. Allows using null to remove any specified user values (null would
>>> also be the default), similar to how we would do it with
>>> ObjectProperty. No need for another property like a boolean value.
>>> 2. Allows changing individual axes and binding to each axis
>>> independently, which was a disadvantage of Point3D.
>>> 3. With how Valhalla is coming along, it's highly likely that there
>>> would be no auto-boxing cost as Double will behave like a primitive.
>>>
>>> Disadvantages:
>>> 1. Using null as the special value does not indicate well that the
>>> default behavior is using the center of the node, but there is no
>>> indication of it now, except in documentation which will be done anyway.
>>> 2. ObjectProperty does not have the specialized methods
>>> inherited from DoubleExpression (like #add), so it is more difficult to
>>> work with mathematically.
>>>
>>> This addresses questions 1 and 2. The 2nd point in the disadvantages
>>> makes this not too appealing for me, but the other options are also
>>> problematic.
>>>
>>> As for question 3, I think we have to. The main goal of the PR is adding
>>> pivot properties to ScaleTransition and RotateTransition. The various
>>> transitions work by changing values in Node (FadeTransform 

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Nir Lisker]

The special case of "center of the node" (the computed pivot) is the
current behavior, and it needs to be preserved for backwards compatibility.
This is why we were discussing the out of band values issues to begin with.

Reading the rest of what you wrote makes me think I didn't understand your
terminology. Does the "relativePivot" switch between normalized coordinates
and non-normalized coordinates, both in the coordinate system of the node?

On Sat, Aug 21, 2021 at 11:23 PM Michael Strauß 
wrote:

> I think that „computed pivot“ is both an unnecessary terminology, and
> really only one special case of a pivot coordinate in unit space where 0/0
> is the top-left corner of the node, and 1/1 is the bottom-right corner of
> the node (which is what I referred to as „relative“ coordinates).
>
> Quite often, it can be more useful to define pivots in unit space, because
> it’s an easy answer to a problem like „rotate the node 45 degrees around
> its top-left corner“. Special-casing the 0.5/0.5 unit coordinate and not
> allowing any other feels like a lackluster API, and increases the effort
> for developers to solve a very common problem.
>
> From an implementation perspective, there’s not much of a difference in
> development and maintenance cost. The projection from unit space to pixel
> space needs to happen anyway (that’s the „computed“ part in „computed
> pivot“), and allowing any coordinate rather than the 0.5/0.5 midpoint is
> only a single multiplication away.
>
>
>
>
> On Saturday, August 21, 2021, Kevin Rushforth 
> wrote:
>
>> I didn't page in enough of the discussion before. I remember now why we
>> need separate pivots for rotate and scale, so thank you for reminding me.
>> Btw, I don't think that necessarily means we need a separate switch for
>> whether to use computed vs explicit for each (but that would be a
>> possibility).
>>
>> I agree with the points raised about relative versus "absolute". While it
>> is an intriguing idea, it probably doesn't fit here.
>>
>> While it is a clever idea to use an ObjectProperty rather than a
>> DoubleProperty so we have an out of band value to use for "compute this" I
>> don't think that we should do it that way for a few reasons. First, it's
>> inconsistent with all other number based properties, in a way that could
>> cause usability issues (e.g., you couldn't just pass pivotXProperty()
>> directly to a method that expects a DoubleProperty). Second, I don't like
>> the implications of having separate "auto-compute" flags on each of X, Y,
>> and Z. Third, is the documentation issue you mentioned.
>>
>> So amending my earlier answers to the three questions:
>>
>> 1. A single boolean property for whether to use a compute pivot (the
>> default) vs an explicit pivot; this would apply to both rotate and scale
>> pivots.
>> 2. 3 separate doubles (using DoubleProperty).
>> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties.
>>
>> -- Kevin
>>
>> On 8/21/2021 6:19 AM, Nir Lisker wrote:
>>
>> In the previous time this was discussed I suggested a 3rd option, in
>> addition to ObjectProperty and 3 DoubleProperties, which is 3
>> ObjectPropertys.
>>
>> Advantages:
>> 1. Allows using null to remove any specified user values (null would also
>> be the default), similar to how we would do it with
>> ObjectProperty. No need for another property like a boolean value.
>> 2. Allows changing individual axes and binding to each axis
>> independently, which was a disadvantage of Point3D.
>> 3. With how Valhalla is coming along, it's highly likely that there would
>> be no auto-boxing cost as Double will behave like a primitive.
>>
>> Disadvantages:
>> 1. Using null as the special value does not indicate well that the
>> default behavior is using the center of the node, but there is no
>> indication of it now, except in documentation which will be done anyway.
>> 2. ObjectProperty does not have the specialized methods inherited
>> from DoubleExpression (like #add), so it is more difficult to work with
>> mathematically.
>>
>> This addresses questions 1 and 2. The 2nd point in the disadvantages
>> makes this not too appealing for me, but the other options are also
>> problematic.
>>
>> As for question 3, I think we have to. The main goal of the PR is adding
>> pivot properties to ScaleTransition and RotateTransition. The various
>> transitions work by changing values in Node (FadeTransform changes opacity,
>> RotateTransition changes rotate and rotationAxis etc.). If we don't have
>> separate pivots for rotation and scale in Node, how can we implement these
>> in the transitions? They surely can't use the same one, both because it
>> will be confusing and there will be synching issues. Think about creating 1
>> RotateTransition and 1 ScaleTransition with different pivots. The order in
>> which you start them will matter because one will change the other (and
>> if forceSync is enabled then one will override the other mid-transition).
>> Having these pivots on 

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Michael Strauß]

I think that „computed pivot“ is both an unnecessary terminology, and
really only one special case of a pivot coordinate in unit space where 0/0
is the top-left corner of the node, and 1/1 is the bottom-right corner of
the node (which is what I referred to as „relative“ coordinates).

Quite often, it can be more useful to define pivots in unit space, because
it’s an easy answer to a problem like „rotate the node 45 degrees around
its top-left corner“. Special-casing the 0.5/0.5 unit coordinate and not
allowing any other feels like a lackluster API, and increases the effort
for developers to solve a very common problem.

>From an implementation perspective, there’s not much of a difference in
development and maintenance cost. The projection from unit space to pixel
space needs to happen anyway (that’s the „computed“ part in „computed
pivot“), and allowing any coordinate rather than the 0.5/0.5 midpoint is
only a single multiplication away.




On Saturday, August 21, 2021, Kevin Rushforth 
wrote:

> I didn't page in enough of the discussion before. I remember now why we
> need separate pivots for rotate and scale, so thank you for reminding me.
> Btw, I don't think that necessarily means we need a separate switch for
> whether to use computed vs explicit for each (but that would be a
> possibility).
>
> I agree with the points raised about relative versus "absolute". While it
> is an intriguing idea, it probably doesn't fit here.
>
> While it is a clever idea to use an ObjectProperty rather than a
> DoubleProperty so we have an out of band value to use for "compute this" I
> don't think that we should do it that way for a few reasons. First, it's
> inconsistent with all other number based properties, in a way that could
> cause usability issues (e.g., you couldn't just pass pivotXProperty()
> directly to a method that expects a DoubleProperty). Second, I don't like
> the implications of having separate "auto-compute" flags on each of X, Y,
> and Z. Third, is the documentation issue you mentioned.
>
> So amending my earlier answers to the three questions:
>
> 1. A single boolean property for whether to use a compute pivot (the
> default) vs an explicit pivot; this would apply to both rotate and scale
> pivots.
> 2. 3 separate doubles (using DoubleProperty).
> 3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties.
>
> -- Kevin
>
> On 8/21/2021 6:19 AM, Nir Lisker wrote:
>
> In the previous time this was discussed I suggested a 3rd option, in
> addition to ObjectProperty and 3 DoubleProperties, which is 3
> ObjectPropertys.
>
> Advantages:
> 1. Allows using null to remove any specified user values (null would also
> be the default), similar to how we would do it with
> ObjectProperty. No need for another property like a boolean value.
> 2. Allows changing individual axes and binding to each axis independently,
> which was a disadvantage of Point3D.
> 3. With how Valhalla is coming along, it's highly likely that there would
> be no auto-boxing cost as Double will behave like a primitive.
>
> Disadvantages:
> 1. Using null as the special value does not indicate well that the default
> behavior is using the center of the node, but there is no indication of it
> now, except in documentation which will be done anyway.
> 2. ObjectProperty does not have the specialized methods inherited
> from DoubleExpression (like #add), so it is more difficult to work with
> mathematically.
>
> This addresses questions 1 and 2. The 2nd point in the disadvantages makes
> this not too appealing for me, but the other options are also problematic.
>
> As for question 3, I think we have to. The main goal of the PR is adding
> pivot properties to ScaleTransition and RotateTransition. The various
> transitions work by changing values in Node (FadeTransform changes opacity,
> RotateTransition changes rotate and rotationAxis etc.). If we don't have
> separate pivots for rotation and scale in Node, how can we implement these
> in the transitions? They surely can't use the same one, both because it
> will be confusing and there will be synching issues. Think about creating 1
> RotateTransition and 1 ScaleTransition with different pivots. The order in
> which you start them will matter because one will change the other (and
> if forceSync is enabled then one will override the other mid-transition).
> Having these pivots on Node for direct usage is convenient, but I see it
> as a secondary goal. It is more of a necessity for the transitions. Notice
> that the JBS issue [1] is aggregating 3 issues because they are
> interdependent.
>
> As for Michael's proposal, it has the benefit of getting rid of the
> special computed value of the center of the node and making it clear what
> the default is.
> I'm not sure what Michael means by "absolute coordinates", I assume it's
> relative to the parent, and that "relative to the layout bounds" means
> relative to the node. This way, setting to 0.5 with "relative to the layout
> bounds" 

Re: [External] : Re: Pivot properties [was: Enhancements for JavaFX 18]

[Kevin Rushforth]

I didn't page in enough of the discussion before. I remember now why we 
need separate pivots for rotate and scale, so thank you for reminding 
me. Btw, I don't think that necessarily means we need a separate switch 
for whether to use computed vs explicit for each (but that would be a 
possibility).


I agree with the points raised about relative versus "absolute". While 
it is an intriguing idea, it probably doesn't fit here.


While it is a clever idea to use an ObjectProperty rather than a 
DoubleProperty so we have an out of band value to use for "compute this" 
I don't think that we should do it that way for a few reasons. First, 
it's inconsistent with all other number based properties, in a way that 
could cause usability issues (e.g., you couldn't just pass 
pivotXProperty() directly to a method that expects a DoubleProperty). 
Second, I don't like the implications of having separate "auto-compute" 
flags on each of X, Y, and Z. Third, is the documentation issue you 
mentioned.


So amending my earlier answers to the three questions:

1. A single boolean property for whether to use a compute pivot (the 
default) vs an explicit pivot; this would apply to both rotate and scale 
pivots.

2. 3 separate doubles (using DoubleProperty).
3. Yes. Separate rotatePivot{X,Y,Z} and scalePivot{X,Y,Z} properties.

-- Kevin

On 8/21/2021 6:19 AM, Nir Lisker wrote:
In the previous time this was discussed I suggested a 3rd option, in 
addition to ObjectProperty and 3 DoubleProperties, which is 3 
ObjectPropertys.


Advantages:
1. Allows using null to remove any specified user values (null would 
also be the default), similar to how we would do it with 
ObjectProperty. No need for another property like a boolean 
value.
2. Allows changing individual axes and binding to each axis 
independently, which was a disadvantage of Point3D.
3. With how Valhalla is coming along, it's highly likely that there 
would be no auto-boxing cost as Double will behave like a primitive.


Disadvantages:
1. Using null as the special value does not indicate well that the 
default behavior is using the center of the node, but there is no 
indication of it now, except in documentation which will be done anyway.
2. ObjectProperty does not have the specialized methods 
inherited from DoubleExpression (like #add), so it is more difficult 
to work with mathematically.


This addresses questions 1 and 2. The 2nd point in the disadvantages 
makes this not too appealing for me, but the other options are also 
problematic.


As for question 3, I think we have to. The main goal of the PR is 
adding pivot properties to ScaleTransition and RotateTransition. The 
various transitions work by changing values in Node (FadeTransform 
changes opacity, RotateTransition changes rotate and rotationAxis 
etc.). If we don't have separate pivots for rotation and scale in 
Node, how can we implement these in the transitions? They surely can't 
use the same one, both because it will be confusing and there will be 
synching issues. Think about creating 1 RotateTransition and 1 
ScaleTransition with different pivots. The order in which you start 
them will matter because one will change the other (and if forceSync 
is enabled then one will override the other mid-transition).
Having these pivots on Node for direct usage is convenient, but I see 
it as a secondary goal. It is more of a necessity for the transitions. 
Notice that the JBS issue [1] is aggregating 3 issues because they are 
interdependent.


As for Michael's proposal, it has the benefit of getting rid of the 
special computed value of the center of the node and making it clear 
what the default is.
I'm not sure what Michael means by "absolute coordinates", I assume 
it's relative to the parent, and that "relative to the layout bounds" 
means relative to the node. This way, setting to 0.5 with "relative to 
the layout bounds" will indeed mean the center of the node.

I find some inconsistency issues with the relativePivot idea:
1. The Scale, Rotate, and Shear transforms use the parent coordinates. 
That means that if I set a pivoted scale transform on the node, and 
then use a pivoted scale transition (keeping the default), the pivot 
will not be the same. This would be very confusing I think.
2. TranslateTransition has a toX property (and Y and Z) that always 
uses the parent coordinates. That means that if I use a translate 
transition and a scale transition (keeping the default), I will be 
working in 2 coordinate systems simultaneously. Also confusing for me.
3. Switching between local and global coordinate systems is a more 
general issue, and solving it locally just for pivots of 2 transitions 
seems incomplete and out of place to me in this patch.


To expand on point 3, I see 3 generally useful systems: node, parent, 
and scene. We have methods that transform from one to the other. 
Despite those, I also find it a lot of work to transform between 
coordinate systems. This leads me to believe that 

Re: Pivot properties [was: Enhancements for JavaFX 18]

[Nir Lisker]

In the previous time this was discussed I suggested a 3rd option, in
addition to ObjectProperty and 3 DoubleProperties, which is 3
ObjectPropertys.

Advantages:
1. Allows using null to remove any specified user values (null would also
be the default), similar to how we would do it with
ObjectProperty. No need for another property like a boolean value.
2. Allows changing individual axes and binding to each axis independently,
which was a disadvantage of Point3D.
3. With how Valhalla is coming along, it's highly likely that there would
be no auto-boxing cost as Double will behave like a primitive.

Disadvantages:
1. Using null as the special value does not indicate well that the default
behavior is using the center of the node, but there is no indication of it
now, except in documentation which will be done anyway.
2. ObjectProperty does not have the specialized methods inherited
from DoubleExpression (like #add), so it is more difficult to work with
mathematically.

This addresses questions 1 and 2. The 2nd point in the disadvantages makes
this not too appealing for me, but the other options are also problematic.

As for question 3, I think we have to. The main goal of the PR is adding
pivot properties to ScaleTransition and RotateTransition. The various
transitions work by changing values in Node (FadeTransform changes opacity,
RotateTransition changes rotate and rotationAxis etc.). If we don't have
separate pivots for rotation and scale in Node, how can we implement these
in the transitions? They surely can't use the same one, both because it
will be confusing and there will be synching issues. Think about creating 1
RotateTransition and 1 ScaleTransition with different pivots. The order in
which you start them will matter because one will change the other (and
if forceSync is enabled then one will override the other mid-transition).
Having these pivots on Node for direct usage is convenient, but I see it as
a secondary goal. It is more of a necessity for the transitions. Notice
that the JBS issue [1] is aggregating 3 issues because they are
interdependent.

As for Michael's proposal, it has the benefit of getting rid of the special
computed value of the center of the node and making it clear what the
default is.
I'm not sure what Michael means by "absolute coordinates", I assume it's
relative to the parent, and that "relative to the layout bounds" means
relative to the node. This way, setting to 0.5 with "relative to the layout
bounds" will indeed mean the center of the node.
I find some inconsistency issues with the relativePivot idea:
1. The Scale, Rotate, and Shear transforms use the parent coordinates. That
means that if I set a pivoted scale transform on the node, and then use a
pivoted scale transition (keeping the default), the pivot will not be the
same. This would be very confusing I think.
2. TranslateTransition has a toX property (and Y and Z) that always uses
the parent coordinates. That means that if I use a translate transition and
a scale transition (keeping the default), I will be working in 2 coordinate
systems simultaneously. Also confusing for me.
3. Switching between local and global coordinate systems is a more general
issue, and solving it locally just for pivots of 2 transitions seems
incomplete and out of place to me in this patch.

To expand on point 3, I see 3 generally useful systems: node, parent, and
scene. We have methods that transform from one to the other. Despite those,
I also find it a lot of work to transform between coordinate systems. This
leads me to believe that the idea of toggling between coordinate systems
tries to solve a broader issue, one that touches both transforms and
transitions (including node properties). As a result, I think that we
should implement the current proposal of adding pivots by using the current
coordinate system that everything else uses (parent), and then think about
better ways of handling coordinate system transformations more generally.

[1] https://bugs.openjdk.java.net/browse/JDK-8234712

On Thu, Aug 19, 2021 at 11:35 PM Kevin Rushforth 
wrote:

> The idea of adding explicit pivot properties was met with general
> agreement as long as we preserve compatibility (meaning that an
> auto-computed pivot at the center of the bounds must remain the default).
>
> The questions are around what form the API should take. They basically
> boil down to:
>
> 1. How do we indicate whether the pivot is computed vs explicitly
> specified?
> 2. Should the pivot position be 3 doubles or a Point3D
> 3. Do we need a separate pivot for rotation vs scaling
>
> My quick thoughts (although I might be able to be persuaded otherwise) are:
>
> 1) a boolean property
> 2) 3 separate doubles
> 3) no
>
> Michael's proposal of a couple months ago [1] would match those answers,
> and is an interesting approach that I hadn't considered before. The
> question then is whether want the additional flexibility that it provides
> and whether it is worth the additional 

Pivot properties [was: Enhancements for JavaFX 18]

[Kevin Rushforth]

The idea of adding explicit pivot properties was met with general 
agreement as long as we preserve compatibility (meaning that an 
auto-computed pivot at the center of the bounds must remain the default).


The questions are around what form the API should take. They basically 
boil down to:


1. How do we indicate whether the pivot is computed vs explicitly specified?
2. Should the pivot position be 3 doubles or a Point3D
3. Do we need a separate pivot for rotation vs scaling

My quick thoughts (although I might be able to be persuaded otherwise) are:

1) a boolean property
2) 3 separate doubles
3) no

Michael's proposal of a couple months ago [1] would match those answers, 
and is an interesting approach that I hadn't considered before. The 
question then is whether want the additional flexibility that it 
provides and whether it is worth the additional implementation, 
documentation, and testing that would be needed. It can be a discussion 
point. I'd like to know what Nir thinks of that idea.


I think we can discuss the details of the API in the PR, although while 
it is Draft, many people will miss the discussion (since it doesn't get 
sent to the mailing list), so it might be better to at get high-level 
agreement on the answers to the outstanding API questions on this list?


-- Kevin

[1] https://github.com/openjdk/jfx/pull/53#issuecomment-822667918


On 8/19/2021 12:03 PM, Nir Lisker wrote:


I'd like to see pivot properties move forward.
The PR seems to be a bit stale, as it has been sitting around for
almost two years.


Me too, but there was no decision as to the implementation type. We 
can continue the discussion on the PR at this point I think.


On Fri, Aug 13, 2021 at 2:32 AM Michael Strauß 
mailto:michaelstr...@gmail.com>> wrote:


I'd like to see pivot properties move forward.
The PR seems to be a bit stale, as it has been sitting around for
almost two years.

PR: https://github.com/openjdk/jfx/pull/53



Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>>:
>
> Now that JavaFX 17 is in RDP2, we can turn more attention to bug
fixes
> and enhancement requests for JavaFX 18. It's the summer, so
there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests
moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547

> PR: https://github.com/openjdk/jfx/pull/563


>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921

> PR: https://github.com/openjdk/jfx/pull/548


>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225

> PR: https://github.com/openjdk/jfx/pull/475


>
> * Improve property system to facilitate correct usage (minus the
binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642

> PR: https://github.com/openjdk/jfx/pull/590


(Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on
how to
> proceed)
>
> * Undecorated interactive stage style (still in early
discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on
openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Thank you to all who added additional items that they wish to see for 
JavaFX 18. I haven't forgotten about this thread. I'll answer most of 
them some time in the next week or so.


Worth noting is that there is limited bandwidth for enhancements. Every 
feature has to pull its own weight, meaning we need to factor in the 
cost of implementing, reviewing, testing, and maintaining it, as well as 
the opportunity cost of not doing something else.


Those enhancements that have reached general consensus, are far enough 
along in the process that we have a good idea how much they will "cost", 
and have a willing contributor and sponsor (for contributors who are not 
Committers), are more likely to make JavaFX 18.


-- Kevin


On 7/30/2021 5:56 AM, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes 
and enhancement requests for JavaFX 18. It's the summer, so there may 
be delays as some people are out at various times (including me), but 
I would like to get some of the outstanding enhancement requests 
moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: Enhancements for JavaFX 18

[Nir Lisker]

>
> I'd like to see pivot properties move forward.
> The PR seems to be a bit stale, as it has been sitting around for
> almost two years.


Me too, but there was no decision as to the implementation type. We can
continue the discussion on the PR at this point I think.

On Fri, Aug 13, 2021 at 2:32 AM Michael Strauß 
wrote:

> I'd like to see pivot properties move forward.
> The PR seems to be a bit stale, as it has been sitting around for
> almost two years.
>
> PR: https://github.com/openjdk/jfx/pull/53
>
> Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth
> :
> >
> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> > and enhancement requests for JavaFX 18. It's the summer, so there may be
> > delays as some people are out at various times (including me), but I
> > would like to get some of the outstanding enhancement requests moving
> > over the next few weeks.
> >
> > Specifically, I'd like to see the following proceed:
> >
> > * Transparent backgrounds in WebView
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> > PR: https://github.com/openjdk/jfx/pull/563
> >
> > * Add DirectionalLight
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> > PR: https://github.com/openjdk/jfx/pull/548
> >
> > * CSS pseudoclasses :focus-visible and :focus-within
> > https://bugs.openjdk.java.net/browse/JDK-8268225
> > PR: https://github.com/openjdk/jfx/pull/475
> >
> > * Improve property system to facilitate correct usage (minus the binary
> > incompatible API change)
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> > PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >
> > And maybe the following:
> >
> > * Add CSS themes as a first-class concept (need a consensus on how to
> > proceed)
> >
> > * Undecorated interactive stage style (still in early discussion, but
> > the concept looks interesting and useful)
> >
> > There are probably others I'm forgetting.
> >
> > Each of the above should be discussed in their own thread on openjfx-dev
> > rather than a reply to this thread.
> >
> > -- Kevin
> >
> >
>

Re: Enhancements for JavaFX 18

[Michael Strauß]

I'd like to see pivot properties move forward.
The PR seems to be a bit stale, as it has been sitting around for
almost two years.

PR: https://github.com/openjdk/jfx/pull/53

Am Fr., 30. Juli 2021 um 14:57 Uhr schrieb Kevin Rushforth
:
>
> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> PR: https://github.com/openjdk/jfx/pull/563
>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> PR: https://github.com/openjdk/jfx/pull/548
>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225
> PR: https://github.com/openjdk/jfx/pull/475
>
> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
>
> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>

Re: Enhancements for JavaFX 18

[Thiago Milczarek Sayão]

Hi,

For the long term solution I would ditch Gtk and use libwayland directly.

Inspiration can come from:
https://gitlab.gnome.org/GNOME/gtk/-/blob/master/gdk/wayland/gdksurface-wayland.c

For the short term solution, maybe remove the usage of X11 specific
functions and replace for existing Gdk ones and let it handle.
By letting gdk handle it it would be necessary to bump up the min required
version, so maybe bundle it with javafx.

The long term solution is interesting because:
* We have the full power of anything supported on wayland;
* Gtk is a full toolkit.


- Cheers







Em ter., 10 de ago. de 2021 às 12:45, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:

> Johan can comment on the details, but I think that is a matter of
> investigation.
>
> As with the AWT work which is under discussion, there are two related,
> but different deliverables that should be looked at:
>
> 1. Running the existing JavaFX GTK port on Wayland in X11 compatibility
> mode
> 2. A native JavaFX Wayland port
>
> For both of them, we need a solution to the same "robot" problems that
> AWT and other libraries face (there is no standard way to control the
> mouse or to read pixels from the screen).
>
> The fact that we already use GTK for most things should make #2 easier,
> and it might be able to share a lot of the code, but it very likely will
> need to be its ow backend, since it can't use X11.
>
> In thinking out loud, one thing to consider might be to have a single
> glass GTK platform with different native libraries for Wayland and X11,
> since we already have that support to handle gtk2 and gtk3. Maybe
> something like:
>
> gtk2 (legacy and only for X11)
> gtk3-x11
> gtk3-wayland
> gtk4-x11
> gtk4-wayland
>
> Not sure whether that makes sense or not.
>
> I imagine that 1 should be feasible in the JavaFX 18 time frame. A
> native Wayland port will be a lot of work, but since JavaFX already uses
> GTK for most things, it should be significantly less work than AWT will be.
>
> -- Kevin
>
>
> On 8/10/2021 8:24 AM, Thiago Milczarek Sayão wrote:
> > Hi Johan,
> >
> > Would you prefer a pure Wayland backend or support it with gdk/GTK on top
> > of the current glass backend?
> >
> > Cheers
> >
> > Em ter, 10 de ago de 2021 07:52, Johan Vos 
> escreveu:
> >
> >> I think we (everyone committing/reviewing in openjdk/jfx) did a great
> job
> >> with the 17-work: an impressive amount of old and annoying bugs are
> fixed.
> >> For 18 and beyond, I believe we have to keep working on those old
> issues --
> >> at least if they are still relevant.
> >> Also, I am 100% ok with the list of issues Kevin mentioned that need to
> be
> >> moved forward now.
> >>
> >> Apart from that, I want to have support for Metal and Wayland in JavaFX
> 18.
> >>
> >> - Johan
> >>
> >> On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth <
> >> kevin.rushfo...@oracle.com>
> >> wrote:
> >>
> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> >>> and enhancement requests for JavaFX 18. It's the summer, so there may
> be
> >>> delays as some people are out at various times (including me), but I
> >>> would like to get some of the outstanding enhancement requests moving
> >>> over the next few weeks.
> >>>
> >>> Specifically, I'd like to see the following proceed:
> >>>
> >>> * Transparent backgrounds in WebView
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> >>> PR: https://github.com/openjdk/jfx/pull/563
> >>>
> >>> * Add DirectionalLight
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> >>> PR: https://github.com/openjdk/jfx/pull/548
> >>>
> >>> * CSS pseudoclasses :focus-visible and :focus-within
> >>> https://bugs.openjdk.java.net/browse/JDK-8268225
> >>> PR: https://github.com/openjdk/jfx/pull/475
> >>>
> >>> * Improve property system to facilitate correct usage (minus the binary
> >>> incompatible API change)
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >>>
> >>> And maybe the following:
> >>>
> >>> * Add CSS themes as a first-class concept (need a consensus on how to
> >>> proceed)
> >>>
> >>> * Undecorated interactive stage style (still in early discussion, but
> >>> the concept looks interesting and useful)
> >>>
> >>> There are probably others I'm forgetting.
> >>>
> >>> Each of the above should be discussed in their own thread on
> openjfx-dev
> >>> rather than a reply to this thread.
> >>>
> >>> -- Kevin
> >>>
> >>>
> >>>
>
>

Re: Enhancements for JavaFX 18

[Nir Lisker]

>
> * Add DirectionalLight
>

I'll note that this is the first in a line of a few other enhancements, so
by no means the only one I'll want to get into 18. The problem is that they
change the same areas of the code, so they block each other.


On Fri, Jul 30, 2021 at 3:59 PM Kevin Rushforth 
wrote:

> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> PR: https://github.com/openjdk/jfx/pull/563
>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> PR: https://github.com/openjdk/jfx/pull/548
>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225
> PR: https://github.com/openjdk/jfx/pull/475
>
> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
>
> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>
>

Re: Enhancements for JavaFX 18

[Dirk Lemmermann]

Frosted glas / blurred background for stages!

> Am 11.08.2021 um 22:07 schrieb Thiago Milczarek Sayão 
> :
> 
> Hi,
> 
> One feature I will probably submit is touch events on Linux.
> 
> Cheers.
> 
> Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth <
> kevin.rushfo...@oracle.com> escreveu:
> 
>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
>> and enhancement requests for JavaFX 18. It's the summer, so there may be
>> delays as some people are out at various times (including me), but I
>> would like to get some of the outstanding enhancement requests moving
>> over the next few weeks.
>> 
>> Specifically, I'd like to see the following proceed:
>> 
>> * Transparent backgrounds in WebView
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>> PR: https://github.com/openjdk/jfx/pull/563
>> 
>> * Add DirectionalLight
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>> PR: https://github.com/openjdk/jfx/pull/548
>> 
>> * CSS pseudoclasses :focus-visible and :focus-within
>> https://bugs.openjdk.java.net/browse/JDK-8268225
>> PR: https://github.com/openjdk/jfx/pull/475
>> 
>> * Improve property system to facilitate correct usage (minus the binary
>> incompatible API change)
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>> 
>> And maybe the following:
>> 
>> * Add CSS themes as a first-class concept (need a consensus on how to
>> proceed)
>> 
>> * Undecorated interactive stage style (still in early discussion, but
>> the concept looks interesting and useful)
>> 
>> There are probably others I'm forgetting.
>> 
>> Each of the above should be discussed in their own thread on openjfx-dev
>> rather than a reply to this thread.
>> 
>> -- Kevin
>> 
>> 
>> 

Re: Enhancements for JavaFX 18

[Thiago Milczarek Sayão]

Hi,

One feature I will probably submit is touch events on Linux.

Cheers.

Em sex., 30 de jul. de 2021 às 09:59, Kevin Rushforth <
kevin.rushfo...@oracle.com> escreveu:

> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> PR: https://github.com/openjdk/jfx/pull/563
>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> PR: https://github.com/openjdk/jfx/pull/548
>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225
> PR: https://github.com/openjdk/jfx/pull/475
>
> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
>
> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>
>

Re: Enhancements for JavaFX 18

[Pedro Duque Vieira]

.. on one client project I'm involved in, I ended up having to use a static
image instead of rendering the text through JavaFX because of the
difference in text rendering quality.

On Wed, Aug 11, 2021 at 4:14 PM Pedro Duque Vieira <
pedro.duquevie...@gmail.com> wrote:

> OK thanks Phillip!
>
> Sorry, I might not have done the best job in reporting the issue back then
> (it's been a while, it was in 2014) :-)
>
> I have an example of the exact same Segoe UI font. One is from Photoshop
> using the text tool with a selected font and the other is from a JavaFX
> using the same font. The difference is very noticeable.
> Would you be interested in seeing the two pictures? If so, how can I share
> them?
>
> Thanks again,
>
> On Tue, Aug 10, 2021 at 5:50 PM Philip Race 
> wrote:
>
>> Well .. if you know you were the reporter, then it narrows down the JBS
>> search from thousands to less than 10 :-)
>>
>> https://bugs.openjdk.java.net/browse/JDK-8092298
>>
>> Near as I can tell, that is an issue where we are comparing the FX use of
>> DirectWrite with
>> unknown usage and configuration of some Windows bundled apps and maybe we
>> aren't
>> even sure it is the same font ..  there was a lot of back and forth there.
>>
>> -phil.
>>
>> On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
>>
>> I've filed the bug a long time ago so I can't remember exactly the bug ID
>> or the title I gave it.
>>
>> Do you want me to file a new one? Do you want me to attach sample images
>> (I think you need to do some work around to attach images to a javafx bug
>> report?)?
>>
>> Thanks Philip
>>
>> On Mon, Aug 9, 2021 at 4:06 PM Philip Race 
>> wrote:
>>
>>> That would be a separate piece of work.  I can't imagine much if any
>>> overlap.
>>> Is there a useful bug ID for what you are referring to ?
>>> The glyph images come from DirectWrite on Windows so I am not sure if
>>> there's something specific ..
>>>
>>> -phil.
>>>
>>> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:
>>>
>>> Hi!
>>>
>>> @Phil Race  If you're going to tackle font
>>> rendering, would it also be possible to work on Windows font rendering? I
>>> find that Windows font rendering is generally much worse than Mac's.
>>>
>>> One example is, for instance, trying to render "Segoe UI" (the Windows
>>> default font) , or "Segoe UI Light"  font (or whatever variant) with a big
>>> font size. The font appears pixelated..
>>>
>>> Thanks,
>>>
>>>
 +1. It is something I intend to get to for 18.
>>>
>>>
>>> -phil.
>>>
>>>
>>> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
 > May I humbly suggest fixing font rendering color fringe issues on
 macOS
>>>
>>>
>>> --
>>> Pedro Duque Vieira - https://www.pixelduke.com
>>>
>>>
>>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>>
>>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>


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

Re: Enhancements for JavaFX 18

[Pedro Duque Vieira]

OK thanks Phillip!

Sorry, I might not have done the best job in reporting the issue back then
(it's been a while, it was in 2014) :-)

I have an example of the exact same Segoe UI font. One is from Photoshop
using the text tool with a selected font and the other is from a JavaFX
using the same font. The difference is very noticeable.
Would you be interested in seeing the two pictures? If so, how can I share
them?

Thanks again,

On Tue, Aug 10, 2021 at 5:50 PM Philip Race  wrote:

> Well .. if you know you were the reporter, then it narrows down the JBS
> search from thousands to less than 10 :-)
>
> https://bugs.openjdk.java.net/browse/JDK-8092298
>
> Near as I can tell, that is an issue where we are comparing the FX use of
> DirectWrite with
> unknown usage and configuration of some Windows bundled apps and maybe we
> aren't
> even sure it is the same font ..  there was a lot of back and forth there.
>
> -phil.
>
> On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
>
> I've filed the bug a long time ago so I can't remember exactly the bug ID
> or the title I gave it.
>
> Do you want me to file a new one? Do you want me to attach sample images
> (I think you need to do some work around to attach images to a javafx bug
> report?)?
>
> Thanks Philip
>
> On Mon, Aug 9, 2021 at 4:06 PM Philip Race  wrote:
>
>> That would be a separate piece of work.  I can't imagine much if any
>> overlap.
>> Is there a useful bug ID for what you are referring to ?
>> The glyph images come from DirectWrite on Windows so I am not sure if
>> there's something specific ..
>>
>> -phil.
>>
>> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:
>>
>> Hi!
>>
>> @Phil Race  If you're going to tackle font
>> rendering, would it also be possible to work on Windows font rendering? I
>> find that Windows font rendering is generally much worse than Mac's.
>>
>> One example is, for instance, trying to render "Segoe UI" (the Windows
>> default font) , or "Segoe UI Light"  font (or whatever variant) with a big
>> font size. The font appears pixelated..
>>
>> Thanks,
>>
>>
>>> +1. It is something I intend to get to for 18.
>>
>>
>> -phil.
>>
>>
>> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
>>> > May I humbly suggest fixing font rendering color fringe issues on macOS
>>
>>
>> --
>> Pedro Duque Vieira - https://www.pixelduke.com
>>
>>
>>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>
>

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

Re: Enhancements for JavaFX 18

[Philip Race]

Well .. if you know you were the reporter, then it narrows down the JBS 
search from thousands to less than 10 :-)


https://bugs.openjdk.java.net/browse/JDK-8092298

Near as I can tell, that is an issue where we are comparing the FX use 
of DirectWrite with
unknown usage and configuration of some Windows bundled apps and maybe 
we aren't

even sure it is the same font ..  there was a lot of back and forth there.

-phil.

On 8/10/21 3:56 AM, Pedro Duque Vieira wrote:
I've filed the bug a long time ago so I can't remember exactly the bug 
ID or the title I gave it.


Do you want me to file a new one? Do you want me to attach sample 
images (I think you need to do some work around to attach images to a 
javafx bug report?)?


Thanks Philip

On Mon, Aug 9, 2021 at 4:06 PM Philip Race > wrote:


That would be a separate piece of work.  I can't imagine much if
any overlap.
Is there a useful bug ID for what you are referring to ?
The glyph images come from DirectWrite on Windows so I am not sure
if there's something specific ..

-phil.

On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:

Hi!

@Phil Race  If you're going to
tackle font rendering, would it also be possible to work on
Windows font rendering? I find that Windows font rendering is
generally much worse than Mac's.

One example is, for instance, trying to render "Segoe UI" (the
Windows default font) , or "Segoe UI Light"  font (or whatever
variant) with a big font size. The font appears pixelated..

Thanks,

+1. It is something I intend to get to for 18.


-phil.


On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> May I humbly suggest fixing font rendering color fringe
issues on macOS


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






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

Re: [External] : Re: Enhancements for JavaFX 18

[Kevin Rushforth]

I think having prototypes of both a Metal pipeline and native Wayland 
would be good in the JavaFX 18 time frame.


We hope to have something to share on Metal in a month or so. The JavaFX 
Metal pipeline can leverage some of the work done for Java2D in the 
Lanai project.


I'll let Johan comment on what he is thinking of for Wayland. As I 
mentioned in another thread, this will be a lot of work (although not as 
much as AWT / Swing / Java2D).


-- Kevin


On 8/10/2021 3:46 AM, Johan Vos wrote:
I think we (everyone committing/reviewing in openjdk/jfx) did a great 
job with the 17-work: an impressive amount of old and annoying bugs 
are fixed.
For 18 and beyond, I believe we have to keep working on those old 
issues -- at least if they are still relevant.
Also, I am 100% ok with the list of issues Kevin mentioned that need 
to be moved forward now.


Apart from that, I want to have support for Metal and Wayland in 
JavaFX 18.


- Johan

On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth 
mailto:kevin.rushfo...@oracle.com>> wrote:


Now that JavaFX 17 is in RDP2, we can turn more attention to bug
fixes
and enhancement requests for JavaFX 18. It's the summer, so there
may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547

PR: https://github.com/openjdk/jfx/pull/563



* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921

PR: https://github.com/openjdk/jfx/pull/548



* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225

PR: https://github.com/openjdk/jfx/pull/475



* Improve property system to facilitate correct usage (minus the
binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642

PR: https://github.com/openjdk/jfx/pull/590


(Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on
openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kevin Rushforth]

Johan can comment on the details, but I think that is a matter of 
investigation.


As with the AWT work which is under discussion, there are two related, 
but different deliverables that should be looked at:


1. Running the existing JavaFX GTK port on Wayland in X11 compatibility mode
2. A native JavaFX Wayland port

For both of them, we need a solution to the same "robot" problems that 
AWT and other libraries face (there is no standard way to control the 
mouse or to read pixels from the screen).


The fact that we already use GTK for most things should make #2 easier, 
and it might be able to share a lot of the code, but it very likely will 
need to be its ow backend, since it can't use X11.


In thinking out loud, one thing to consider might be to have a single 
glass GTK platform with different native libraries for Wayland and X11, 
since we already have that support to handle gtk2 and gtk3. Maybe 
something like:


gtk2 (legacy and only for X11)
gtk3-x11
gtk3-wayland
gtk4-x11
gtk4-wayland

Not sure whether that makes sense or not.

I imagine that 1 should be feasible in the JavaFX 18 time frame. A 
native Wayland port will be a lot of work, but since JavaFX already uses 
GTK for most things, it should be significantly less work than AWT will be.


-- Kevin


On 8/10/2021 8:24 AM, Thiago Milczarek Sayão wrote:

Hi Johan,

Would you prefer a pure Wayland backend or support it with gdk/GTK on top
of the current glass backend?

Cheers

Em ter, 10 de ago de 2021 07:52, Johan Vos  escreveu:


I think we (everyone committing/reviewing in openjdk/jfx) did a great job
with the 17-work: an impressive amount of old and annoying bugs are fixed.
For 18 and beyond, I believe we have to keep working on those old issues --
at least if they are still relevant.
Also, I am 100% ok with the list of issues Kevin mentioned that need to be
moved forward now.

Apart from that, I want to have support for Metal and Wayland in JavaFX 18.

- Johan

On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth <
kevin.rushfo...@oracle.com>
wrote:


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Thiago Milczarek Sayão]

Hi Johan,

Would you prefer a pure Wayland backend or support it with gdk/GTK on top
of the current glass backend?

Cheers

Em ter, 10 de ago de 2021 07:52, Johan Vos  escreveu:

> I think we (everyone committing/reviewing in openjdk/jfx) did a great job
> with the 17-work: an impressive amount of old and annoying bugs are fixed.
> For 18 and beyond, I believe we have to keep working on those old issues --
> at least if they are still relevant.
> Also, I am 100% ok with the list of issues Kevin mentioned that need to be
> moved forward now.
>
> Apart from that, I want to have support for Metal and Wayland in JavaFX 18.
>
> - Johan
>
> On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth <
> kevin.rushfo...@oracle.com>
> wrote:
>
> > Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> > and enhancement requests for JavaFX 18. It's the summer, so there may be
> > delays as some people are out at various times (including me), but I
> > would like to get some of the outstanding enhancement requests moving
> > over the next few weeks.
> >
> > Specifically, I'd like to see the following proceed:
> >
> > * Transparent backgrounds in WebView
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> > PR: https://github.com/openjdk/jfx/pull/563
> >
> > * Add DirectionalLight
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> > PR: https://github.com/openjdk/jfx/pull/548
> >
> > * CSS pseudoclasses :focus-visible and :focus-within
> > https://bugs.openjdk.java.net/browse/JDK-8268225
> > PR: https://github.com/openjdk/jfx/pull/475
> >
> > * Improve property system to facilitate correct usage (minus the binary
> > incompatible API change)
> > JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> > PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >
> > And maybe the following:
> >
> > * Add CSS themes as a first-class concept (need a consensus on how to
> > proceed)
> >
> > * Undecorated interactive stage style (still in early discussion, but
> > the concept looks interesting and useful)
> >
> > There are probably others I'm forgetting.
> >
> > Each of the above should be discussed in their own thread on openjfx-dev
> > rather than a reply to this thread.
> >
> > -- Kevin
> >
> >
> >
>

Re: Enhancements for JavaFX 18

[Pedro Duque Vieira]

I've filed the bug a long time ago so I can't remember exactly the bug ID
or the title I gave it.

Do you want me to file a new one? Do you want me to attach sample images (I
think you need to do some work around to attach images to a javafx bug
report?)?

Thanks Philip

On Mon, Aug 9, 2021 at 4:06 PM Philip Race  wrote:

> That would be a separate piece of work.  I can't imagine much if any
> overlap.
> Is there a useful bug ID for what you are referring to ?
> The glyph images come from DirectWrite on Windows so I am not sure if
> there's something specific ..
>
> -phil.
>
> On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:
>
> Hi!
>
> @Phil Race  If you're going to tackle font
> rendering, would it also be possible to work on Windows font rendering? I
> find that Windows font rendering is generally much worse than Mac's.
>
> One example is, for instance, trying to render "Segoe UI" (the Windows
> default font) , or "Segoe UI Light"  font (or whatever variant) with a big
> font size. The font appears pixelated..
>
> Thanks,
>
>
>> +1. It is something I intend to get to for 18.
>
>
> -phil.
>
>
> On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
>> > May I humbly suggest fixing font rendering color fringe issues on macOS
>
>
> --
> Pedro Duque Vieira - https://www.pixelduke.com
>
>
>

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

Re: Enhancements for JavaFX 18

[Johan Vos]

I think we (everyone committing/reviewing in openjdk/jfx) did a great job
with the 17-work: an impressive amount of old and annoying bugs are fixed.
For 18 and beyond, I believe we have to keep working on those old issues --
at least if they are still relevant.
Also, I am 100% ok with the list of issues Kevin mentioned that need to be
moved forward now.

Apart from that, I want to have support for Metal and Wayland in JavaFX 18.

- Johan

On Fri, Jul 30, 2021 at 2:58 PM Kevin Rushforth 
wrote:

> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> PR: https://github.com/openjdk/jfx/pull/563
>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> PR: https://github.com/openjdk/jfx/pull/548
>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225
> PR: https://github.com/openjdk/jfx/pull/475
>
> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
>
> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>
>

Re: Enhancements for JavaFX 18

[Philip Race]

That would be a separate piece of work.  I can't imagine much if any 
overlap.

Is there a useful bug ID for what you are referring to ?
The glyph images come from DirectWrite on Windows so I am not sure if 
there's something specific ..


-phil.

On 8/9/21 3:44 AM, Pedro Duque Vieira wrote:

Hi!

@Phil Race  If you're going to tackle 
font rendering, would it also be possible to work on Windows font 
rendering? I find that Windows font rendering is generally much worse 
than Mac's.


One example is, for instance, trying to render "Segoe UI" (the Windows 
default font) , or "Segoe UI Light"  font (or whatever variant) with a 
big font size. The font appears pixelated..


Thanks,

+1. It is something I intend to get to for 18.


-phil.


On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> May I humbly suggest fixing font rendering color fringe issues
on macOS


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

Re: Enhancements for JavaFX 18

[Abu Abdullah]

I would really like to see opus codec support for the media playback

On Fri, 30 Jul 2021, 4:59 pm Kevin Rushforth, 
wrote:

> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I
> would like to get some of the outstanding enhancement requests moving
> over the next few weeks.
>
> Specifically, I'd like to see the following proceed:
>
> * Transparent backgrounds in WebView
> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> PR: https://github.com/openjdk/jfx/pull/563
>
> * Add DirectionalLight
> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> PR: https://github.com/openjdk/jfx/pull/548
>
> * CSS pseudoclasses :focus-visible and :focus-within
> https://bugs.openjdk.java.net/browse/JDK-8268225
> PR: https://github.com/openjdk/jfx/pull/475
>
> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>
> And maybe the following:
>
> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
>
> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
>
> There are probably others I'm forgetting.
>
> Each of the above should be discussed in their own thread on openjfx-dev
> rather than a reply to this thread.
>
> -- Kevin
>
>
>

Re: Enhancements for JavaFX 18

[Pedro Duque Vieira]

Hi!

@Phil Race  If you're going to tackle font
rendering, would it also be possible to work on Windows font rendering? I
find that Windows font rendering is generally much worse than Mac's.

One example is, for instance, trying to render "Segoe UI" (the Windows
default font) , or "Segoe UI Light"  font (or whatever variant) with a big
font size. The font appears pixelated..

Thanks,


> +1. It is something I intend to get to for 18.


-phil.


On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:
> > May I humbly suggest fixing font rendering color fringe issues on macOS


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

Re: Enhancements for JavaFX 18

[Ty Young]

Oh, and to add one more feature: ability to add context menu to specific 
TreeView cells without going through cell factory.



On 7/30/21 7:56 AM, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes 
and enhancement requests for JavaFX 18. It's the summer, so there may 
be delays as some people are out at various times (including me), but 
I would like to get some of the outstanding enhancement requests 
moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: Enhancements for JavaFX 18

[Ty Young]

On 8/4/21 5:35 PM, John Hendrikx wrote:



On 04/08/2021 19:05, Ty Young wrote:


* A late "showing" property for when the application has been shown to
the user and all first viewing UI components have had their sizes
calculated and are being displayed, if it doesn't exist already and I'm
completely blind.


Do you mean a property that is true if the current node is visible, 
attached to a scene which is attached to a window which is currently 
showing?


This can be achieved with a small util that takes a Node and returns
an ObservableValue.  I can dig up the code, I use this all 
the time to automatically unbind bindings when UI parts become invisible.



Something like that, yes.




--John

Re: Enhancements for JavaFX 18

[dev . infeo]

+1. Implementing the system tray api in JavaFX and not relying on AWT would be 
nice thing.

On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel <
sebastian.stenzel at gmail.com 
https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev> wrote:

> +1 for a proper system tray api
>
> > Am 04.08.2021 um 16:47 schrieb Scott Palmer  > https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev>:
> >
> > +1 to that.
> >
> > I would also like to see some progress with system tray support and
> microphone & webcam access.
> >
> > Scott
> >
> >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg <
> fastegal at swingempire.de 
> https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev> wrote:
> >>
> >> 
> >> my suggestion would be the longstanding commit-edit-on-focus-lost -
> solved by an enhancement to the editing api on virtualized controls
> >>
> >> -- Jeanette
> >>
> >> Zitat von Kevin Rushforth  >> https://mail.openjdk.java.net/mailman/listinfo/openjfx-dev>:
> >>
> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I would
> like to get some of the outstanding enhancement requests moving over the
> next few weeks.
> >>>
> >>> Specifically, I'd like to see the following proceed:
> >>>
> >>> * Transparent backgrounds in WebView
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> >>> PR: https://github.com/openjdk/jfx/pull/563
> >>>
> >>> * Add DirectionalLight
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> >>> PR: https://github.com/openjdk/jfx/pull/548
> >>>
> >>> * CSS pseudoclasses :focus-visible and :focus-within
> >>> https://bugs.openjdk.java.net/browse/JDK-8268225
> >>> PR: https://github.com/openjdk/jfx/pull/475
> >>>
> >>> * Improve property system to facilitate correct usage (minus the
> binary incompatible API change)
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >>>
> >>> And maybe the following:
> >>>
> >>> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
> >>>
> >>> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
> >>>
> >>> There are probably others I'm forgetting.
> >>>
> >>> Each of the above should be discussed in their own thread on
> openjfx-dev rather than a reply to this thread.
> >>>
> >>> -- Kevin
> >>
> >>
> >>
> >
>

Re: Enhancements for JavaFX 18

[John Hendrikx]

On 04/08/2021 19:05, Ty Young wrote:


* A late "showing" property for when the application has been shown to
the user and all first viewing UI components have had their sizes
calculated and are being displayed, if it doesn't exist already and I'm
completely blind.


Do you mean a property that is true if the current node is visible, 
attached to a scene which is attached to a window which is currently 
showing?


This can be achieved with a small util that takes a Node and returns
an ObservableValue.  I can dig up the code, I use this all the 
time to automatically unbind bindings when UI parts become invisible.


--John

Re: Enhancements for JavaFX 18

[John Hendrikx]

Perhaps:

Fluent bindings for ObservableValue https://github.com/openjdk/jfx/pull/434

It was received well I think, and there was some interest from Nir 
Lisker to work on a proposal.


--John

On 30/07/2021 14:56, Kevin Rushforth wrote:

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I
would like to get some of the outstanding enhancement requests moving
over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to
proceed)

* Undecorated interactive stage style (still in early discussion, but
the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev
rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Philip Race]

+1. It is something I intend to get to for 18.

-phil.

On 8/4/21 1:10 PM, Kirill Grouchnikov wrote:

May I humbly suggest fixing font rendering color fringe issues on macOS

On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel <
sebastian.sten...@gmail.com> wrote:


+1 for a proper system tray api


Am 04.08.2021 um 16:47 schrieb Scott Palmer :

+1 to that.

I would also like to see some progress with system tray support and

microphone & webcam access.

Scott


On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg <

faste...@swingempire.de> wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost -

solved by an enhancement to the editing api on virtualized controls

-- Jeanette

Zitat von Kevin Rushforth :


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes

and enhancement requests for JavaFX 18. It's the summer, so there may be
delays as some people are out at various times (including me), but I would
like to get some of the outstanding enhancement requests moving over the
next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the

binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to

proceed)

* Undecorated interactive stage style (still in early discussion, but

the concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on

openjfx-dev rather than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Kirill Grouchnikov]

May I humbly suggest fixing font rendering color fringe issues on macOS

On Wed, Aug 4, 2021 at 3:54 PM Sebastian Stenzel <
sebastian.sten...@gmail.com> wrote:

> +1 for a proper system tray api
>
> > Am 04.08.2021 um 16:47 schrieb Scott Palmer :
> >
> > +1 to that.
> >
> > I would also like to see some progress with system tray support and
> microphone & webcam access.
> >
> > Scott
> >
> >> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg <
> faste...@swingempire.de> wrote:
> >>
> >> 
> >> my suggestion would be the longstanding commit-edit-on-focus-lost -
> solved by an enhancement to the editing api on virtualized controls
> >>
> >> -- Jeanette
> >>
> >> Zitat von Kevin Rushforth :
> >>
> >>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I would
> like to get some of the outstanding enhancement requests moving over the
> next few weeks.
> >>>
> >>> Specifically, I'd like to see the following proceed:
> >>>
> >>> * Transparent backgrounds in WebView
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> >>> PR: https://github.com/openjdk/jfx/pull/563
> >>>
> >>> * Add DirectionalLight
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> >>> PR: https://github.com/openjdk/jfx/pull/548
> >>>
> >>> * CSS pseudoclasses :focus-visible and :focus-within
> >>> https://bugs.openjdk.java.net/browse/JDK-8268225
> >>> PR: https://github.com/openjdk/jfx/pull/475
> >>>
> >>> * Improve property system to facilitate correct usage (minus the
> binary incompatible API change)
> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> >>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >>>
> >>> And maybe the following:
> >>>
> >>> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
> >>>
> >>> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
> >>>
> >>> There are probably others I'm forgetting.
> >>>
> >>> Each of the above should be discussed in their own thread on
> openjfx-dev rather than a reply to this thread.
> >>>
> >>> -- Kevin
> >>
> >>
> >>
> >
>

Re: Enhancements for JavaFX 18

[Ty Young]

You want a list of bugs that could be fixed? Today's your lucky day!


* Resizing a JavaFX window under Linux (still) causes graphical 
glitches, needing -Dprism.forceUploadingPainter=true or, IIRC, software 
rendering to "fix".



* Resizing ALSO causes graphical glitching on the bottom and right sides 
on both Windows AND Linux.



* Resizing an app with a TableView in view results in the TableView's 
integrated scrollbars flickering in and out of existence when there is 
plenty of space left. The less UI content there is, the less this is 
likely to happen - but it absolutely does happen with *just* a TableView 
as the root node, you gotta play with it.



* Resizing the application from the left causes UI jitter.


* JavaFX in general seems to have trouble keeping up with user resizing. 
Rapidly resizing an application with a DividerPane(TreeView left, 
content right) results in inconsistent positioning than if it was done 
slowly, in the very least.



* Alt tabbing with a UI component being selected(Slider thumb, 
scrollbar) results in that component's color being stuck in whatever 
color is the CSS selected state.



* You can middle and right click drag a slider thumb and scroll bars, 
which does not trigger a CSS state change, which is not consistent with 
MenuBar items.



* JavaFX does not seem to calculate the size of a GridPane or TilePane 
with elements correctly. This results in content in ScrollPanes that is 
clearly larger in height than the viewport but ScrollPane does not show 
its scrollbars - only mouse wheel works without forcing the scrollbars 
to always show or transition state bugs when putting a GridPane/TilePane 
inside a TitlePane(or maybe it's TilePane -> TitlePane -> TilePane 
that's the issue? No clue.)



* XY Chart data that is off screen (-1, -1) has lines drawn to them 
despite being... off screen. Bug or feature?



* Setting the Y axis side to Side.RIGHT causes a white space with custom 
CSS: https://imgur.com/a/4P1Oj1Q.



Might be missing some.


A few features, while I'm here:


* API property to force a TableView's height to be the exact amount 
needed to display its headers and all its rows.



* API to disable TableView's scrollbars completely.


* A late "showing" property for when the application has been shown to 
the user and all first viewing UI components have had their sizes 
calculated and are being displayed, if it doesn't exist already and I'm 
completely blind.



On 7/30/21 7:56 AM, Kevin Rushforth wrote:
Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes 
and enhancement requests for JavaFX 18. It's the summer, so there may 
be delays as some people are out at various times (including me), but 
I would like to get some of the outstanding enhancement requests 
moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the 
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on 
openjfx-dev rather than a reply to this thread.


-- Kevin

Re: Enhancements for JavaFX 18

[Sebastian Stenzel]

+1 for a proper system tray api

> Am 04.08.2021 um 16:47 schrieb Scott Palmer :
> 
> +1 to that. 
> 
> I would also like to see some progress with system tray support and 
> microphone & webcam access. 
> 
> Scott
> 
>> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg  
>> wrote:
>> 
>> 
>> my suggestion would be the longstanding commit-edit-on-focus-lost - solved 
>> by an enhancement to the editing api on virtualized controls
>> 
>> -- Jeanette
>> 
>> Zitat von Kevin Rushforth :
>> 
>>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
>>> enhancement requests for JavaFX 18. It's the summer, so there may be delays 
>>> as some people are out at various times (including me), but I would like to 
>>> get some of the outstanding enhancement requests moving over the next few 
>>> weeks.
>>> 
>>> Specifically, I'd like to see the following proceed:
>>> 
>>> * Transparent backgrounds in WebView
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>>> PR: https://github.com/openjdk/jfx/pull/563
>>> 
>>> * Add DirectionalLight
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>>> PR: https://github.com/openjdk/jfx/pull/548
>>> 
>>> * CSS pseudoclasses :focus-visible and :focus-within
>>> https://bugs.openjdk.java.net/browse/JDK-8268225
>>> PR: https://github.com/openjdk/jfx/pull/475
>>> 
>>> * Improve property system to facilitate correct usage (minus the binary 
>>> incompatible API change)
>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>>> 
>>> And maybe the following:
>>> 
>>> * Add CSS themes as a first-class concept (need a consensus on how to 
>>> proceed)
>>> 
>>> * Undecorated interactive stage style (still in early discussion, but the 
>>> concept looks interesting and useful)
>>> 
>>> There are probably others I'm forgetting.
>>> 
>>> Each of the above should be discussed in their own thread on openjfx-dev 
>>> rather than a reply to this thread.
>>> 
>>> -- Kevin
>> 
>> 
>> 
> 

Re: Enhancements for JavaFX 18

[Scott Palmer]

+1 to that. 

I would also like to see some progress with system tray support and microphone 
& webcam access. 

Scott

> On Aug 4, 2021, at 7:07 AM, Jeanette Winzenburg  
> wrote:
> 
> 
> my suggestion would be the longstanding commit-edit-on-focus-lost - solved by 
> an enhancement to the editing api on virtualized controls
> 
> -- Jeanette
> 
> Zitat von Kevin Rushforth :
> 
>> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
>> enhancement requests for JavaFX 18. It's the summer, so there may be delays 
>> as some people are out at various times (including me), but I would like to 
>> get some of the outstanding enhancement requests moving over the next few 
>> weeks.
>> 
>> Specifically, I'd like to see the following proceed:
>> 
>> * Transparent backgrounds in WebView
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
>> PR: https://github.com/openjdk/jfx/pull/563
>> 
>> * Add DirectionalLight
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
>> PR: https://github.com/openjdk/jfx/pull/548
>> 
>> * CSS pseudoclasses :focus-visible and :focus-within
>> https://bugs.openjdk.java.net/browse/JDK-8268225
>> PR: https://github.com/openjdk/jfx/pull/475
>> 
>> * Improve property system to facilitate correct usage (minus the binary 
>> incompatible API change)
>> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
>> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
>> 
>> And maybe the following:
>> 
>> * Add CSS themes as a first-class concept (need a consensus on how to 
>> proceed)
>> 
>> * Undecorated interactive stage style (still in early discussion, but the 
>> concept looks interesting and useful)
>> 
>> There are probably others I'm forgetting.
>> 
>> Each of the above should be discussed in their own thread on openjfx-dev 
>> rather than a reply to this thread.
>> 
>> -- Kevin
> 
> 
> 

Re: Enhancements for JavaFX 18

[Dirk Lemmermann]

+1

Tom Eugelink  schrieb am Mi. 4. Aug. 2021 um 16:31:

> +1
>
> On 2021-08-04 11:58, Jeanette Winzenburg wrote:
> >
> > my suggestion would be the longstanding commit-edit-on-focus-lost -
> solved by an enhancement to the editing api on virtualized controls
> >
> > -- Jeanette
> >
> > Zitat von Kevin Rushforth :
> >
> >> Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes
> and enhancement requests for JavaFX 18. It's the summer, so there may be
> delays as some people are out at various times (including me), but I would
> like to get some of the outstanding enhancement requests moving over the
> next few weeks.
> >>
> >> Specifically, I'd like to see the following proceed:
> >>
> >> * Transparent backgrounds in WebView
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
> >> PR: https://github.com/openjdk/jfx/pull/563
> >>
> >> * Add DirectionalLight
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
> >> PR: https://github.com/openjdk/jfx/pull/548
> >>
> >> * CSS pseudoclasses :focus-visible and :focus-within
> >> https://bugs.openjdk.java.net/browse/JDK-8268225
> >> PR: https://github.com/openjdk/jfx/pull/475
> >>
> >> * Improve property system to facilitate correct usage (minus the binary
> incompatible API change)
> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
> >> PR: https://github.com/openjdk/jfx/pull/590 (Draft)
> >>
> >> And maybe the following:
> >>
> >> * Add CSS themes as a first-class concept (need a consensus on how to
> proceed)
> >>
> >> * Undecorated interactive stage style (still in early discussion, but
> the concept looks interesting and useful)
> >>
> >> There are probably others I'm forgetting.
> >>
> >> Each of the above should be discussed in their own thread on
> openjfx-dev rather than a reply to this thread.
> >>
> >> -- Kevin
> >
> >
> >
>
> --
Dirk Lemmermann

Software & Consulting
Zurich, Switzerland
+41-(0)79-800-23-20
http://www.dlsc.com
mailto:dlemmerm...@gmail.com

Re: Enhancements for JavaFX 18

[Tom Eugelink]

+1

On 2021-08-04 11:58, Jeanette Winzenburg wrote:


my suggestion would be the longstanding commit-edit-on-focus-lost - solved by 
an enhancement to the editing api on virtualized controls

-- Jeanette

Zitat von Kevin Rushforth :


Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes and 
enhancement requests for JavaFX 18. It's the summer, so there may be delays as 
some people are out at various times (including me), but I would like to get 
some of the outstanding enhancement requests moving over the next few weeks.

Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary 
incompatible API change)
JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to proceed)

* Undecorated interactive stage style (still in early discussion, but the 
concept looks interesting and useful)

There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev rather 
than a reply to this thread.

-- Kevin

Re: Enhancements for JavaFX 18

[Jeanette Winzenburg]

my suggestion would be the longstanding commit-edit-on-focus-lost -  
solved by an enhancement to the editing api on virtualized controls


-- Jeanette

Zitat von Kevin Rushforth :

Now that JavaFX 17 is in RDP2, we can turn more attention to bug  
fixes and enhancement requests for JavaFX 18. It's the summer, so  
there may be delays as some people are out at various times  
(including me), but I would like to get some of the outstanding  
enhancement requests moving over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the  
binary incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how  
to proceed)


* Undecorated interactive stage style (still in early discussion,  
but the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on  
openjfx-dev rather than a reply to this thread.


-- Kevin

Enhancements for JavaFX 18

[Kevin Rushforth]

Now that JavaFX 17 is in RDP2, we can turn more attention to bug fixes 
and enhancement requests for JavaFX 18. It's the summer, so there may be 
delays as some people are out at various times (including me), but I 
would like to get some of the outstanding enhancement requests moving 
over the next few weeks.


Specifically, I'd like to see the following proceed:

* Transparent backgrounds in WebView
JBS: https://bugs.openjdk.java.net/browse/JDK-8090547
PR: https://github.com/openjdk/jfx/pull/563

* Add DirectionalLight
JBS: https://bugs.openjdk.java.net/browse/JDK-8234921
PR: https://github.com/openjdk/jfx/pull/548

* CSS pseudoclasses :focus-visible and :focus-within
https://bugs.openjdk.java.net/browse/JDK-8268225
PR: https://github.com/openjdk/jfx/pull/475

* Improve property system to facilitate correct usage (minus the binary 
incompatible API change)

JBS: https://bugs.openjdk.java.net/browse/JDK-8268642
PR: https://github.com/openjdk/jfx/pull/590 (Draft)

And maybe the following:

* Add CSS themes as a first-class concept (need a consensus on how to 
proceed)


* Undecorated interactive stage style (still in early discussion, but 
the concept looks interesting and useful)


There are probably others I'm forgetting.

Each of the above should be discussed in their own thread on openjfx-dev 
rather than a reply to this thread.


-- Kevin