On Fri, 31 May 2024 14:39:00 GMT, Karthik P K wrote:
> The issue is specific to Mac. The glyph positions returned from native side
> for complex text is not handled in the text render logic. This issue is
> observed only when trailing spaces are present along with LTR text mixed with
> RTL tex
The code snippet returns true because if the VertexFormat specifies no
normal data, then the contents of the normals array are valid no matter
what they are, because they are unused. validateNormals() is called
regardless of if normals are used by the VertexFormat which is why it
explicitly include
On Mon, 30 Sep 2024 19:08:22 GMT, Andy Goryachev wrote:
>> Incubating a new feature - rich text control, **RichTextArea**, intended to
>> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane.
>> The main design goal is to provide a control that is complete enough to be
>> u
On Mon, 9 Sep 2024 15:10:00 GMT, Andy Goryachev wrote:
>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java
>> line 1076:
>>
>>> 1074: * When selection exists, deletes selected text. Otherwise,
>>> deletes the character preceding the care
On Mon, 30 Sep 2024 19:08:22 GMT, Andy Goryachev wrote:
>> Incubating a new feature - rich text control, **RichTextArea**, intended to
>> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane.
>> The main design goal is to provide a control that is complete enough to be
>> u
On Tue, 17 Sep 2024 21:21:49 GMT, Andy Goryachev wrote:
>> modules/jfx.incubator.richtext/src/main/java/jfx/incubator/scene/control/richtext/RichTextArea.java
>> line 314:
>>
>>> 312: /**
>>> 313: * Creates the instance with the in-memory model {@link
>>> RichTextModel}.
>>> 314:
On Fri, 13 Sep 2024 21:21:56 GMT, Andy Goryachev wrote:
> > `fromInlineStyle` docs that it is equivalent to `fromStyles(style)`.
>
> good point, thanks!
>
> edit: actually, these are hidden behind RichParagraph.Builder methods, so
> they can be made package-protected. Also, StyleAttributeMap.f
> Incubating a new feature - rich text control, **RichTextArea**, intended to
> bridge the functional gap with Swing and its StyledEditorKit/JEditorPane. The
> main design goal is to provide a control that is complete enough to be useful
> out-of-the box, as well as open to extension by the appl
On Fri, 27 Sep 2024 13:07:15 GMT, Kevin Rushforth wrote:
>> This PR modifies the header and footer of the javadoc-generated API docs to
>> add "DRAFT $VER-ea+$BLD" to clearly identify an ea build of the docs, and
>> also to make it clear which build number the docs refer to. This matches was
>
On Mon, 30 Sep 2024 14:49:08 GMT, Andy Goryachev wrote:
> Thank you! Is the `DEAD_ACUTE + c` problem limited to the US International
> keyboard, or it also happens with other (e.g. German, French?) keyboards?
I have entered [JDK-8341256](https://bugs.openjdk.org/browse/JDK-8341256) with
some b
The glass code on Windows does its own dead key processing so at certain points
it must clear the dead key state that the OS is maintaining. It does this by
simulating a SPACE key press but this only works reliably if the SPACE key is
pressed without any modifiers.
Currently the code is picking
On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote:
> This change modifies `ScrollPaneBehavior` to only consume keys that are
> targetted at it. As `KeyEvent`s are in almost all cases only intended for
> the targetted node (as visually that's where the user expects the keyboard
> input to
On Thu, 26 Sep 2024 21:17:55 GMT, John Hendrikx wrote:
> This change modifies `ScrollPaneBehavior` to only consume keys that are
> targetted at it. As `KeyEvent`s are in almost all cases only intended for
> the targetted node (as visually that's where the user expects the keyboard
> input to
Gluon maintains JavaFX 17 and 21, so Johan can answer that.
There is no maintainer for the JavaFX 8 or 11 code lines in OpenJDK.
-- Kevin
On 9/30/2024 7:55 AM, Johan Corveleyn wrote:
On Sat, Sep 28, 2024 at 3:02 PM Martin Fox wrote:
On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote:
The
On Sat, Sep 28, 2024 at 3:02 PM Martin Fox wrote:
>
> On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote:
>
> > The standard across all platforms is:
> >
> > - A dead key followed by a composable character generates the composed
> > character. For example, a circumflex dead key followed by an 'e
On Fri, 27 Sep 2024 14:29:17 GMT, Martin Fox wrote:
> The standard across all platforms is:
>
> - A dead key followed by a composable character generates the composed
> character. For example, a circumflex dead key followed by an 'e' should
> generate 'ê'.
> - A dead key followed by a characte
On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>>
On Fri, 27 Sep 2024 22:22:27 GMT, Michael Strauß wrote:
>> This PR completes the CSS Transitions story (see #870) by adding
>> interpolation support for backgrounds and borders, making them targetable by
>> transitions.
>>
>> `Background` and `Border` objects are deeply immutable, but not
>>
I would first try to figure out if the code in the snippet I gave is
actually correct. If it is, then the vertex format has a functional use. If
it's not, then we can think about what to do with it. I didn't look into
it, but on the face of it, it doesn't look like the unused normals should
be vali
19 matches
Mail list logo
