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
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
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
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
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
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
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
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
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
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 ;)
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
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
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
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
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
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 /
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.
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
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.
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.
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
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
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
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
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
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,
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
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
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.
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,
>
> 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
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
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
>
> * 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
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:
>
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
.. 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!
>
>
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
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
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
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
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
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
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
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!
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
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"
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
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
+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
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
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
+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
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
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
+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
+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
+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
+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
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.
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
61 matches
Mail list logo
