On Wed, 8 Nov 2023 22:30:34 GMT, Nir Lisker wrote:
> Moves the filter setting of the samplers from the device parameters
> configuration to the use-site, allowing for dynamic changes in the sampler.
> This PR does internal plumbing work only to bring it close to the ES2
> pipeline. A followup
Hello,
due to the scaling problems on Linux with
https://bugs.openjdk.org/browse/JDK-8326428, I tried to implement a
workaround by manually setting glass.gtk.uiScale to the appropriate
value. However, when this value is not 100%, small images, in this case
40x40, often have artifacts around
On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda wrote:
> Hi all,
>
> This pull request contains a clean backport of commit
> [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd)
> from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>
> The
On Fri, 23 Feb 2024 22:10:02 GMT, Michael Strauß wrote:
> > What about SWT ? It looks like SWT also supports dark mode since version
> > 4.12 [1][2].
> > [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac
> > [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357
>
On Fri, 23 Feb 2024 21:58:37 GMT, Michael Strauß wrote:
>> Platform preferences detection doesn't pick up effective macOS system
>> preferences if AWT owns the NSApplication and has set its NSAppearance to a
>> fixed value.
>>
>> The workaround is to set the system property
>>
On Thu, 22 Feb 2024 22:28:40 GMT, Nir Lisker wrote:
>> Overhaul to the `PhongMaterial` documentation (and a bit to its superclass
>> `Material`). Except for the introduction, I divided the documentation into 3
>> sections: qualitative explanation, mathematical model (I wouldn't think it
>>
On Fri, 23 Feb 2024 22:32:23 GMT, Andy Goryachev wrote:
>> `@return` statements usually state this condition explicitly, like
>> `Map#get`: "the value to which the specified key is mapped, or `null` if
>> this map contains no mapping for the key".
>
> My point is that it should be mentioned in
On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker wrote:
>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs
>> in `Node` and `Scene`.
>>
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
>> system property, while for `Node` it isn't (which
On Fri, 23 Feb 2024 22:32:16 GMT, Nir Lisker wrote:
>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs
>> in `Node` and `Scene`.
>>
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
>> system property, while for `Node` it isn't (which
On Fri, 23 Feb 2024 22:28:59 GMT, Nir Lisker wrote:
> Only `Scene` has the RTL system property checked.
I suppose because Scene must INHERIT this value from the system?
-
PR Comment: https://git.openjdk.org/jfx/pull/1379#issuecomment-1962094000
On Fri, 26 Jan 2024 17:32:02 GMT, Martin Fox wrote:
> In the Mac glass code the presence of "marked" text (which is tracked in the
> nsAttrBuffer) signals that an IME is active. In this state the current code
> assumes that when NSTextInputContext handles a `keyDown:` it will either
>
On Fri, 23 Feb 2024 21:58:30 GMT, Nir Lisker wrote:
>> I don't mind either way.
>
> `@return` statements usually state this condition explicitly, like `Map#get`:
> "the value to which the specified key is mapped, or `null` if this map
> contains no mapping for the key".
My point is that it
On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote:
> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in
> `Node` and `Scene`.
>
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
> system property, while for `Node` it isn't (which means
> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in
> `Node` and `Scene`.
>
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
> system property, while for `Node` it isn't (which means `SubScene` will be
> different from `Scene`). Not sure
On Mon, 19 Feb 2024 17:13:58 GMT, Anirvan Sarkar wrote:
> What about SWT ? It looks like SWT also supports dark mode since version 4.12
> [1][2].
>
> [1] : https://eclipse.dev/eclipse/news/4.12/platform_isv.php#dark-theme-mac
> [2] : https://bugs.eclipse.org/bugs/show_bug.cgi?id=540357
I
On Fri, 23 Feb 2024 20:14:43 GMT, Kevin Rushforth wrote:
>> Michael Strauß has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> address review comments
>
> modules/javafx.graphics/src/main/java/com/sun/glass/ui/mac/MacApplication.java
>
On Fri, 23 Feb 2024 19:38:20 GMT, Kevin Rushforth wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/layout/AnchorPane.java
>> line 187:
>>
>>> 185: * Returns the child's bottom anchor constraint, if set.
>>> 186: * @param child the child node of an anchor pane
>>> 187:
> Platform preferences detection doesn't pick up effective macOS system
> preferences if AWT owns the NSApplication and has set its NSAppearance to a
> fixed value.
>
> The workaround is to set the system property
> "apple.awt.application.appearance=system".
>
> If this property is not set,
On Fri, 23 Feb 2024 20:16:55 GMT, Nir Lisker wrote:
> I suggest to move the doc to the field.
Yeah that's even better.
-
PR Review Comment: https://git.openjdk.org/jfx/pull/1379#discussion_r1501132703
On Sat, 17 Feb 2024 18:11:09 GMT, Michael Strauß wrote:
>> Platform preferences detection doesn't pick up effective macOS system
>> preferences if AWT owns the NSApplication and has set its NSAppearance to a
>> fixed value.
>>
>> The workaround is to set the system property
>>
On Fri, 23 Feb 2024 19:44:06 GMT, Andy Goryachev wrote:
>> modules/javafx.graphics/src/main/java/javafx/scene/Scene.java line 6272:
>>
>>> 6270: * of text in both worlds.
>>> 6271: *
>>> 6272: * @defaultValue if the system property {@code
>>> javafx.scene.nodeOrientation.RTL} is
On Fri, 23 Feb 2024 19:34:41 GMT, Kevin Rushforth wrote:
>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs
>> in `Node` and `Scene`.
>>
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
>> system property, while for `Node` it isn't
On Fri, 2 Feb 2024 18:43:19 GMT, Martin Fox wrote:
>> In the Mac glass code the presence of "marked" text (which is tracked in the
>> nsAttrBuffer) signals that an IME is active. In this state the current code
>> assumes that when NSTextInputContext handles a `keyDown:` it will either
>>
On Fri, 23 Feb 2024 18:31:10 GMT, Andy Goryachev wrote:
>> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs
>> in `Node` and `Scene`.
>>
>> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
>> system property, while for `Node` it isn't (which
On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote:
> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in
> `Node` and `Scene`.
>
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
> system property, while for `Node` it isn't (which means
Hi all,
I don't use RT controls, so I can't comment about the specifics of this or
other implementations. However, people raised some good points that I would
like to be more specific about.
1. Can the "components" of the RTA be separated out so that other controls
can use them? For example,
On Fri, 23 Feb 2024 17:46:20 GMT, Nir Lisker wrote:
> Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in
> `Node` and `Scene`.
>
> Note that the default value for a `Scene`'s `NodeOrientation` depends on a
> system property, while for `Node` it isn't (which means
Christopher,
-Dglass.gtk.uiScale=`gsettings get org.gnome.desktop.interface
text-scaling-factor`
Probably works.
Em qua., 21 de fev. de 2024 às 01:57, Christopher Schnick <
crschn...@xpipe.io> escreveu:
> So I tested this on my Asahi Fedora Linux KDE setup. So you were right
> about the
Fixes for the `AnchorPane` docs, as well as for the `NodeOrientation` docs in
`Node` and `Scene`.
Note that the default value for a `Scene`'s `NodeOrientation` depends on a
system property, while for `Node` it isn't (which means `SubScene` will be
different from `Scene`). Not sure if this is
On Thu, 22 Feb 2024 23:13:26 GMT, Marius Hanl wrote:
>> This PR fixes the dialog freeze problem once and for all.
>>
>> This one is a bit tricky to understand, here is how it works:
>> This bug happens on every platform, although the implementation of nested
>> event loops differs on every
On Thu, 22 Feb 2024 10:52:08 GMT, Jose Pereda wrote:
> Hi all,
>
> This pull request contains a clean backport of commit
> [ab68b716](https://github.com/openjdk/jfx/commit/ab68b716fbfd807918ca4a1bc096dcf40d9cfcbd)
> from the [openjdk/jfx](https://git.openjdk.org/jfx) repository.
>
> The
This is a good point, Martin.
I would expect the JavaFX RTA to be basic, but extendable - to allow
companies to offer commercial options for particular needs based on it. I
don't see a single RTA component that would be useful for every need.
Use case examples (that I could think of):
- An IDE
On Thu, 15 Feb 2024 20:38:14 GMT, Kevin Rushforth wrote:
> This PR bumps the minimum version of the JDK needed to run JavaFX to **JDK
> 21**.
>
> In order for JavaFX to be able to use newer JDK features, such as code
> snippets (in API docs), record patterns, pattern matching for switch
>
Le 2024-02-23 à 13 h 34, Johan Vos a écrit :
That is not to say that we should not do anything. On the contrary,
I'd love it if we could do more. But in the right place. Stability and
basic features inside OpenJFX, experiments and libraries in the ecosystem.
JavaFX could have a "basic" Rich
Hi,
I agree with what others are saying that perhaps creating and adding this
control is not a priority now for the JavaFX team.
In an ideal world where the JavaFX team had more resources to implement
things (like the team JavaFX had at the time of JavaFX 8 and before), this
would make sense.
Hi,
Interesting remarks.
> Hello,
>
> >> A 3rd party control, RichTextFX already exists -- what is this new
> proposal adding that RichTextFX does not have?
>
> It uses the standard JavaFX VirtualFlow API and and does not need to work
> with reactive streams. RichtextFX depends on several long
Hello,
>> A 3rd party control, RichTextFX already exists -- what is this new
proposal adding that RichTextFX does not have?
It uses the standard JavaFX VirtualFlow API and and does not need to
work with reactive streams. RichtextFX depends on several long
unmaintained libs: ReactFX (last
On Wed, Feb 21, 2024 at 7:09 PM Andy Goryachev
wrote:
> Dear JavaFX developers:
>
...
> Sincerely,
>
> Your friendly JavaFX development team.
>
Not sure I understand that signature. I believe everyone on this list is
part of the JavaFX development team.
I fully agree with John on this.
A RichTextArea is something that can "easily" be developed outside OpenJFX .
There are a number of examples already, e.g. RichTextFX, and our (Gluon)
RichTextArea at
https://github.com/gluonhq/rich-text-area
In the past, we clearly said that this was not a focus
Dear Andy, others,
Thank you for your feedback. Yes, having a one-line TextArea, mocking up a
TextField, that contains a longer text with some sub-strings being able to
style is enough for my use-case.
Anyhow, I agree with others that having the possibility to "style" parts of
other controls
On Thu, 22 Feb 2024 10:33:38 GMT, Karthik P K wrote:
>> A valid concern about specific fonts, similar to
>> https://github.com/openjdk/jfx/pull/1236#issuecomment-1937022815
>>
>> What was the resolution there? To use a hard-coded font based on the
>> platform, or pick an available one from
41 matches
Mail list logo
