Vote: yes
-phil.
There's not many knobs available. Hinting is not enabled - and that's
commonly the case on modern plartforms.
LCD is your best option for readibility of static text, which is why it
is the default for UI Controls,
It should reduce the pixel grid fitting uneveness you highlight but
doesn't elimin
Since we at Oracle don't have or produce Windows ARM JDK binaries,
I don't see a road to anyone here being able to work on it for the
forseeable future.
-phil.
On 6/9/24 2:51 AM, Johan Vos wrote:
Hi Christopher,
The question about Windows. AArch64 increasingly pops up. We did some
local tes
llback \
--include-typedef GSourceFunc \
--include-typedef GError
Em seg., 22 de abr. de 2024 às 13:24, Philip Race
escreveu:
As a reminder, using FFM will require all FX *applications* to
specify --enable-native-access on the command line
Although this is likely coming to JN
As a reminder, using FFM will require all FX *applications* to specify
--enable-native-access on the command line
Although this is likely coming to JNI soon too.
https://docs.oracle.com/en/java/javase/21/core/restricted-methods.html
But one thing to watch out for with FFM is startup + warm up t
in a JEP-like document and is discussed on the mailing list.
That's what we mean when we say "needs a JEP".
On 2/21/2024 9:47 AM, Philip Race wrote:
1) The first thing that jumps out at me is the namespace :
javafx.incubator
The JDK's JEP 11 says "An incubator modu
1) The first thing that jumps out at me is the namespace : javafx.incubator
The JDK's JEP 11 says "An incubator module is identified by
the|jdk.incubator.|prefix in its module name"
It says the same about the packages inside the module.
"An incubating API is identified by the|jdk.incubator.|pre
I already gave a brief explanation of why FX text rendering is what it is.
I will expand on it a bit but a number of the salient points have
already been made by others.
It is unlikely we will make anything other than carefully considered
tweaks, so this is by way of explanation.
I'm not going
Usage of hinting in UIs is on the way out.
macOS stopped applying hints ages ago. Apple also canned LCD text.
High DPI displays are obsoleting the raison d'etre of both of these.
A big problem with hinting is that it distorts both the size and the
shape, so UIs do not scale evenly
and animations
There are several open bug reports of problems in AWT on ubuntu 23.10
(and some on 23.04)
https://bugs.openjdk.org/issues/?jql=project%20%3D%20JDK%20AND%20component%20%3D%20client-libs%20AND%20labels%20in%20(ubuntu23.04%2C%20ubuntu23.10)
Note that GTK is not used to the same extent as it is by
oses
only, the actual indicator might look like a flag or a “ г”):
What do you think?
-andy
*From: *Nir Lisker
*Date: *Thursday, October 19, 2023 at 00:28
*To: *Philip Race
*Cc: *Andy Goryachev ,
openjfx-dev@openjdk.org
*Subject: *Re: [External] : Re: Question: bidi navigation
Thank
So it seems Swing never calls Java2D's TextLayout.getCaretShapes() API
which is what would provide the split carets.
Swing's caret is an instance of javax.swing.text.DefaultCaret which has
support for rendering a "flag" that indicates
the direction of the caret bias.
Split caret is however us
Vote: yes
-phil.
Probably there isn't unless the OS has a way of flagging the binary
So what OS and CPU architecture + specific version are you seeing this on ?
Others might want to try to reproduce this.
-phil.
On 5/23/23 12:31 PM, Davide Perini wrote:
As title.
I'm pretty sure that my JavaFX app is managed by
Vote: yes
-phil.
Vote: yes
-phil.
Those tools as I think you've worked out are Windows-only tools which
use the Windows-only
Java Access Bridge API that ships with JDK.
AccessBridge was designed and built 25 years ago (!) to enable Assistive
Technologies to
work for Swing applications at a time when no platform could do this.
A
Vote: yes
-phil
Vote: yes
-phil.
Vote: yes
-phil.
In the JDK we've only sealed existing classes which provably could not
have been extended by application classes,
so I'm not sure about this ..
also I think that might be the first change that absolutely means FX 21
can only be built with JDK 17 and later ..
-phil
On 2/1/23 8:59 AM, Thiago
Many of the items below (meaning excluding the caret features and app
control of line spacing) are on my list of
things to work on.
phil
On 1/26/23 12:33 PM, Scott Palmer wrote:
[dupe of private message, now including the mailing list]
I've been using RichTextFX to make my own code editor/IDE
Can JavaFX render full colour emojis? Is the greyscale rendering on macOS
intentional?
https://bugs.openjdk.org/browse/JDK-8290866
I was looking at this before we started our winter break, and realised it was
going to be a chunk of work.
So not intentional but anything that ever appeared to wo
Yes
-Phil.
> Very nice! Was the technical session recorded?
In theory, yes, but we are still waiting to see to be sure since so far
only key notes have been posted.
My understanding is that if works out it'll be on the java dev-rel
youtube channel
phil.
On 11/1/22 5:50 PM, Nir Lisker wrote:
Very nice
FX does (of course) support required ligatures, meaning those without
which some script (eg Arabic)
can't even be rendered.
But that is implementation, no API.
So this is about adding an API to request optional ligatures - and other
OpenType features.
For example I think we'd want to support
> this is Java code after all, why would all Java classes for a
platform be platform specific?
There absolutely CAN be such things as platform-specific Java classes in
code that ports to a platform.
OpenJDK is littered with subdirectories named "windows" and "linux" etc.
And it takes great car
All of these requests seem to map to what we added to AWT in JDK 9.
We did this because there'd been Apple specific APIs that came in via the
Apple port but were very iffy in terms of what was supported and it was
not a good idea to formally export them from the new desktop module.
The java.awt.D
Kevin is right. If you look (for a good example) in JDK's java.base
module for "new Error"
you'll be hard-pressed to find Error being thrown in response to a
passed in argument.
The cases I see are when something completely unexpected or "should not
happen" went
wrong in some implementation cod
I've read the various comments so far and so have weighed those and my
view is that
it is about time to move on from JDK11 and think a policy of making the
minimum an LTS is a
reasonable position - so JDK 17 LTS is what comes out of that today.
What to do in future (ie what is the policy) is a
30 matches
Mail list logo
