Re: JavaFX on Windows ARM

[Christopher Schnick]

Is there a rough timeline that you can provide from Oracle's side for 
this? Assuming that it even is on the horizon.


Because as you rightly say, this is the primary building block that 
everything depends on. I also don't know what the status is for other 
vendors right now.


On 10/06/2024 00:15, Philip Race wrote:

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 tests, and the basis modules builds out-of-the-box, but media 
and web modules require more work.
It's definitely helpful that there are GA runners for it now -- 
although the GA is just a basic check.
It would be good to know if someone is compiling media/webkit for 
Win/AArch64.


- Johan


On Sat, Jun 8, 2024 at 10:01 PM Christopher Schnick 
 wrote:


Hello there,

with the latest releases of ARM hardware with Windows I just
wanted to
ask whether there are any plans on officially supporting JavaFX for
Windows on ARM.

There are also now GitHub runners for Windows and Linux that run
on ARM
(see

https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/),

so things have definitely gotten easier with regards to actually
realizing a CI/CD pipeline.

Re: Toolkit Window Decorations

[Christopher Schnick]

I totally agree with the need for better decoration support. I think 
many JavaFX application developers would agree that one big area where 
JavaFX is lacking are window decorations, or the lack thereof. Nowadays 
there are many reasons for having better support/integration for window 
decorations:


- On Windows, decorations are always in white, even if the system 
appearance is set to dark. Also if the application is displaying in dark 
mode while the OS is still in light (all the other way around), the 
window decorations also do not match up with the application style on 
other systems like macOS. It would be very useful to have control over 
the decorations color scheme. Maybe being able to bind a ColorScheme to 
some kind of native window decorations property would help here.


- Having better custom decorations would also be helpful. Especially 
when looking into the future on Linux as described here


- Some way to merge the native decorations with the UI as you see in 
many modern application nowadays would also be nice, but this is not 
that important as the other points in my opinion


On 23/05/2024 13:16, Thiago Milczarek Sayão wrote:

Hi,

At some point we will need "Client Side" decorations on JavaFX to 
support modern gnome desktop on Linux as they moved to have client 
side decorations on everything.
Mutter (the gnome compositor) does not even support "server side" 
decorations. On Wayland it's an extension for KDE only.


Currently, even on Xorg it's a bit hacky when JavaFX needs to set 
total window size (with decorations). It caused too many problems.


Having controls on the titlebar is a nice feature to have, as seen on 
many applications (tabs, hamburger menus, buttons).


I'm not exactly sure on how it should be done. Maybe a Scene property 
that enables its contents to be wrapped in a decoration control?

Would it break applications that walk through the scene graph?

Should it look like Modena and have a JavaFX "identity", or should it 
try to look like the platform it's in?


On Wayland, it would be possible to use a subcompositor to place the 
decoration behind, but I think it would be better if the decoration 
was part of the Scene. It would be less problematic on the variety of 
compositors (Mutter, Kwin, Sway, etc).



-- Thiago

JavaFX on Windows ARM

[Christopher Schnick]

Hello there,

with the latest releases of ARM hardware with Windows I just wanted to 
ask whether there are any plans on officially supporting JavaFX for 
Windows on ARM.


There are also now GitHub runners for Windows and Linux that run on ARM 
(see 
https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/), 
so things have definitely gotten easier with regards to actually 
realizing a CI/CD pipeline.

Re: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized

[Christopher Schnick]

On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao  
wrote:

> Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.
> 
> It seems i3 replies with decorated sizes, even if window is not decorated.
> 
> Won't hurt other WMs.

I can confirm on my system that this PR fixes the issues that I am seeing and 
some users reported. Here is a before and after comparison for context menus 
and tooltips:

![image](https://github.com/openjdk/jfx/assets/72509152/11f8a791-3777-4e52-b318-f994fe465d69)
![image](https://github.com/openjdk/jfx/assets/72509152/1553b2aa-e4da-45b2-a99b-6664270dbd54)

![image](https://github.com/openjdk/jfx/assets/72509152/066b685e-f591-4d21-bdff-ebe1ffdd2937)
![image](https://github.com/openjdk/jfx/assets/72509152/15151785-5e53-442d-a685-a99bea6a51e5)

The tests also pass for me (didn't build webkit though)

-

PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2097459748

Re: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized

[Christopher Schnick]

On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao  
wrote:

> Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.
> 
> It seems i3 replies with decorated sizes, even if window is not decorated.
> 
> Won't hurt other WMs.

So I can reproduce this on my system now and could potentially test this PR. 
How would one go about this, testing a specific PR?

-

PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2094496333

Re: RFR: 8329821: [Linux] When using i3 WM, menus are incorrectly sized

[Christopher Schnick]

On Sat, 6 Apr 2024 17:34:06 GMT, Thiago Milczarek Sayao  
wrote:

> Simple fix to only request `_NET_FRAME_EXTENTS` if window has decoration.
> 
> It seems i3 replies with decorated sizes, even if window is not decorated.
> 
> Won't hurt other WMs.

I recently got a report from a user running the latest xfce version that had 
the same problem where context menus and tooltips were cut off. But this fix is 
specific to i3?

![image](https://github.com/openjdk/jfx/assets/72509152/93e4171c-0e0d-45b6-bc0c-da725ceabd26)

-

PR Comment: https://git.openjdk.org/jfx/pull/1437#issuecomment-2041148672

ImageView has artifacts when uiScale is set on Linux

[Christopher Schnick]

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 the borders:


Original image:

The same does not happen when using the same uiScale on Windows. This 
was done with the latest ea build on Ubuntu 23.10. The exact scale does 
not matter as long it is not 100%.


This is the code I used:

|public class ImageSize extends Application {

    public static void main(String[] args) {
    System.setProperty("glass.gtk.uiScale", "400%");
    Application.launch(ImageSize.class, args);
    }

    @Override
    public void start(Stage primaryStage) throws Exception {
    var img = 
"data:image/png;base64,iVBORw0KGgoNSUhEUgAAACgoCAYAAACM/rhtCXBIWXMAAAEuAAABLgF7cRpNGXRFWHRTb2Z0d2FyZQB3d3cuaW5rc2NhcGUub3Jnm+48GgAACJhJREFUWIXNmHt0VNUVxn/n3nkmE/KCZDJBkCBIxRBIgqBBEKSAi2i7ZAG1tauCheUjARUp6lpW66K11CICoViLq7TlYZ9YFaGtlYfSKJiglPAQwQWBSUzIa5JJ5nlP/7hhXplMEnF1+f01c+539vnO2fvsve+FrznEV2GkcJmzCMlTwM0CPMB2TKyvWuu4fLW2r0pgcdmlEk3hCaSYG8eWW8KrQbQXjm0cevH/KrBouXOKlHIVUpT2g+4D/hjUtNWfbBr66UDXGoBAKQrLnaXAUyAmD3QhQEPIt0VQPFO1yVH91Ql8ViqFTc65IJ4BihJRjaogKCWaltCiRMjdQqirq9bbP/zSAouWSqNmrr9HIJ8ExvRlCOC3j2bS3KGx4jct/aEj4ZBArqnemPtmbxxD7MD8+VI9Z69fKqlbJWB4v1bqRmqygi/Qf76AEhBvTCh3HhKC1dUbHHtjOUrswFm7c4dE/ooBigNobte43BYc6DRdqGTPhDLnzxIKLHi4biyIBQNeoRs2q8Bq/vKZSwhWFS+/dH3kWJSLVUWbPpCLbTUJpow1M3mMmRF2A6McRkZkG3lxSTqnLwY4cNzDqVr/QDQqmlRmAqfjCkQqJQgZuSMenzeI/5zwcuiEN7wrFe6dYeP7M5JJS46OEoMK0/ItTMuHpXfYqLngZ/PudipPeqN4swutpCQJ/vJ+Z9S4kLIE2BRSHPO0JPKv0SCYU2TlxSUZzCq0ApCdprL1scGU35lCWrKClFBzwc+/jnpC894+0sWlJj0Wxw4zUvFgBk/fk4pR1b1z74xkfvqDNEpvSupxhFIyNUrSlR8Fj9bmqgG1R0nKTld55FspzJxg5Z9VXYwfacKergKw56MuXtnTwYXGABNHm3i5LBOAqT+qp9MrKbzORPmdg8i/1gjAB6e8BIJwyw1m/vSem1f2dNDm7pk0hcLwqvWOCxDhYiWo3NqDCXzREuTJra04m4Lc900bAD6/5OltrbwTcWop1rAzbFYFtydI1Rkfi9Zd5sG5Kdw/y8bkMWYAfvyHVnYf6Yq3HACaJkuACxDhYiGVkl5nAC0ROzUYBNfnGlEjAsQWKdASvmgpVoUR2dGhfr4hcbLU86OOCIFySm8TksyCRd2n52wOoghYPMvGluWZODLUbiFhUVfEFo8y8doTg5lRYEFKqGvW4/Kh0pSEAkGEtCgAYx9qsEnBjb3Rp4+zkJas0N6l8b1fXGb7PjcA40aY2LlqCN+9LZnZ3ZcIYMGUJFbOG8Tmskyy01Q0DVa/1sbjr+olcNL1ZnIz1UQK84uWNqeGBFqF/2bilL0ruPVGCwD//tiDq1PjxV0u1u1yoUk9Oa+4exBjhxtD/DnFVr4zLRlFgNcvWflqC69XdnKq1s/pi3pevH28JZFARZo8k0MCNZWE8Zdn17V/eNoXGtu2z81zO1qjeJ85A1y8HC51Pr/koU3N7P9v+DJ9cErPh6McRhJBKromPVikSCgwK02nxQZ3fUtYzN6qLhb+vJEFzzdyxqmfUqdP0tAaXZtruzeQk5HQxQjJFADD/PlSPUvdpERknx+wgkHR42fqjWamj7OQnR5e5MoF8PolDa0aoxyQlqzw5rNZnKsPcPC4h8OnfQPpkCeNfbbGZDiXVVcA9HqtHBkqotvq1scGo/Tof3TcfUsSbW6NtGSFiaNNUc/y7Aby7Dbum0momU2yCJLMgk6vjGNNpxhbMgrEhGWXyoUUGyKfzCiwMLvQyjVZKnl2Q6hEAUipp5qzdX7O1QUYnKpSepO1h/VAEDbvbifJIsizGxiZY2BopiFqg00ujZO1fs43BHjrcBefXoppLCSPGYQUebHGF8+yMXSwyqEaL39+r5OJo03MLrTibA6y8PnGqF2PG2GKK9Djk2zf58YfDHPTbQpv/yQLk1Hw1uEuKk95mTjKxB3FVkbnGnmgoinaiMJwA0J8how+5sUvNSE1Qsbf/cTD9HwLjgyVwutMvF8T7kzumhQWt+51F4UjTUzLt2CzCmZOsLDno3BJmzclCZNR0OWTrP2bC1enxt6PulCUth4b7D7BGiVgEluJ6L9ATw+RO29za+w8oCfnJxekMihJ95PNKphTrAs8dMLLtnfdrH6tDbdHn7vg1nC3Mj7PxJLZeqjv2O/G1RkunZpGjxctATVmQ3CbcuyXdndQ0+4CopNaDLb8o4PzDQHs6SobHsggxapQelMSVpNA02DDGy5Ab/t/904HoLt/zDVGbhhm5IX70zGocLYuwJa9HYmWAmiRweC3K9dd0xWK/sIy52wEu4FeE9S12Qa2LM8k3aZQ2xhAUQS5mSp//6CT53aE3WQxCXY9PYSsVJWTtX5G2g2YjIIvWoMsWd8U6hV7gSalKD1akbOHSDF1h9eezZm0IgDc3tvMVrfG/mNebv6GmWFZhpCr3+0ugVLCoCSFa7MNZKfpGWBIqoqqCs44/Sx7uSWq0sSDQKysrsj5ffh/FKQoLK/fCXJhIiMWk+CV8syo+psIx8/7WbKhCZ+/15x3BdurNzrujRyISbtCmg2BRUBVIisen0RR4LJL44W/ujh43ENDWxB/UOLzSy40Bqg86aXizXaa2zU0TfYpTkg+Fl6W9hiPR57wsHO4UDgCDIn3/LZxFtb+MJ0VW1rYf8wTjxLCzPEW1ixOZ/mvm6PSUwyaAlKZeKzC/nnsg7iF6+gmx3lgHtDjndGg6qmmoS3IweOJxQHsO+ahuV3jqYWpoZIZA79EzIsnrleBANUbHe8JycrYcYHg9EU/L+1q7+sjEQBBDV563cXn9YG4AqVk2dGNOQd6m99nc1G0zLlFSu7vW8qXgdxavTF3USJGryd4BSkubxmSPj+TDRyi0kXnA32y+mOq6JHGHBnwH0GQe/XCAKiTMlB8tGKYsy9iv/tH/WaLNSCnAglfKPrAyaAmln6yKafmKmx8ffA/40AyV2Na31IASUVORK5CYII=";

    var r = new ImageView(img);
    r.setFitWidth(40);
    r.setFitHeight(40);

    var s = new StackPane(r);
    s.setBackground(Background.fill(Color.BLACK));

    var scene = new Scene(s, 100, 100);
    primaryStage.setScene(scene);
    primaryStage.setTitle("Test");
    primaryStage.show();
    }
}|

Is this a bug or a limitation in the renderer?

Best
Christopher Schnick

Re: Proposal: RichTextArea Control (Incubator)

[Christopher Schnick]

Hey Andy and others,

from my perspective as an application developer, I would look for 
providing an abstract but robust implementation that would allow anyone 
to implement such a concrete rich text field without any roadblocks. 
Maybe even going as far as going for a more abstract implementation than 
text areas. I.e. allowing you to define any kind of data model class 
which can be flexibly represented by a set of compound nodes and 
controls and can update and reflect the model state dynamically.


I think that way you would also get a few more people on board who are 
not currently longing for a rich text area because they are either 
satisfied with the existing solutions or their applications that they 
typically work with do not use them. If such a work effort could benefit 
more areas of JavaFX than just rich text editing, people would be happy 
to jump on board.


Instead of creating a RichParagraph.Builder, why not create a more 
generic CompoundControlSegment.Builder, CompoundControl.Builder, 
CompoundControl, etc.? I.e. being able to easily add arbitrary nodes and 
controls in segments/lines, also allowing for an easy way to set style 
classes and inline styles. Being able to bind each node's contents to 
part of the data model, having some undo/redo functionality for this 
model. The StyledAttribute and StyleHandlerRegistry concept can also be 
applied to more than just text areas. And also the idea of the 
ConfigurationParameters to allow for an easy but custom handling of 
other things such as scrollbars for the resulting compound control. This 
would allow developers to use these same principles for other 
implementations as well, for example creating forms. And I can 
definitely find some use for such a concept in other places far away 
from text areas as well.


The proposed actual rich text area can then still be included as a 
concrete implementation of this absraction.


Best
Christopher Schnick

On 21/02/2024 19:07, Andy Goryachev wrote:


Dear JavaFX developers:

We would like to propose 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 application developers.


This is a complex feature with a large API surface that would be 
nearly impossible to get right the first time, even after an extensive 
review.  We are, therefore, introducing this in an incubating module, 
*javafx.incubator.richtext*.   This will allow us to evolve the API in 
future releases without the strict compatibility constraints that 
other JavaFX modules have.


Please take a look at the proposal [0], a list of discussion points 
[1], and the API Specification (javadoc) [2]. While the proposed API 
is ready for review, it isn't complete nor set in stone. We are 
looking for feedback, and will update the proposal based on the 
suggestions we receive from the community.  We encourage you to 
comment either in the mailing list, or by leaving comments inline in a 
draft pull request [3].  For context, the links to the original RFE 
[4] and a list of missing APIs related to rich text [5] are provided 
below.


Sincerely,

Your friendly JavaFX development team.

References

[0] Proposal: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextArea.md


[1] Discussion points: 
https://github.com/andy-goryachev-oracle/Test/blob/rich.jep.review/doc/RichTextArea/RichTextAreaDiscussion.md


[2] API specification (javadoc): 
https://cr.openjdk.org/~angorya/RichTextArea/javadoc


[3] Draft Pull Request for API comments and feedback: 
https://github.com/openjdk/jfx/pull/1374


[4] RichTextArea RFE: https://bugs.openjdk.org/browse/JDK-8301121

[5] Missing APIs related to rich text control: 
https://bugs.openjdk.org/browse/JDK-8300569

Re: UI scaling issues when physical and logical screen resolutions differ on Linux

[Christopher Schnick]

So I tested this on my Asahi Fedora Linux KDE setup. So you were right 
about the scaling-factor being set to 1, but I'm still a little bit 
confused about this situation.


If I go into the KDE settings, and change the display scaling to 150% 
for example, other (native) applications somehow get scaled 
appropriately. However, the scaling-factor property in gsettings is an 
integer and gets rounded down. So if I set display scaling to 150% in 
the settings, it will still get rounded down to one, leading to a wrong 
scaling for JavaFX applications. I would argue that JavaFX applications 
not scaling correctly on KDE systems is not a small issue as it makes 
some applications unusable unless the developer add support for custom 
scaling explicitly. So I have two questions:
- Is the default dpi calculation also error prone? If not, why not 
always use the manual calculation on KDE systems
- Are there better alternatives to the gsettings scaling-factor? 
Something like |org.gnome.desktop.interface text-scaling-factor|


On 16/02/2024 21:31, Martin Fox wrote:

Hi Christopher,

This may be a side-effect of using KDE. To determine the UI scale the 
JavaFX code consults the “scaling-factor” setting in the 
“org.gnome.desktop.interface” schema. You can check this on the 
command line:


gsettings get org.gnome.desktop.interface scaling-factor

This should be 0 so JavaFX can compute the scale itself. If it’s 
greater than 0 that’s the value JavaFX will use for the UI scale.


It appears that a KDE install can set this value to 1. In my case I 
started with the ARM version of Ubuntu server and then installed KDE 
(kubuntu-desktop) and afterward the scaling-factor was 1. This doesn’t 
happen when installing the standard GNOME desktop.


Martin

On Feb 13, 2024, at 2:13 AM, Christopher Schnick  
wrote:


Hello,

several users of our JavaFX applications have reported that the UI 
scale is too small when the physical and logical screen resolutions 
differ on Linux. For example in this case




there is an implicit scaling factor of 150% included as the monitor 
is a 4k display but is using a lowered resolution of 2560x1440. This 
is then further stretched as the OS resolution is 1920x1080, but the 
main problem is that the 150% factor is somehow not getting picked up 
and JavaFX is treating this as a 4k display, thus making everything 
too small. For now these users can use -Dglass.gtk.uiScale=1.5 but 
that is not a nice solution to this problem.


Best
Christopher Schnick

Re: [External] : Re: Platform preferences theme detection

[Christopher Schnick]

Just wanted to let you know that after setting 
apple.awt.application.appearance=system everything works as expected 
now. Thanks for all the work on this great feature. I plan to release 
the next version of our application with platform preferences 
integration soon to production.


On 13/02/2024 20:11, Michael Strauß wrote:

The reason why the values are wrong might be that in PlatformSupport.m
L105, we query [NSApp effectiveApperance], but this always seems to
return the light appearance if JavaFX doesn't own the NSApplication.

On Mon, Feb 12, 2024 at 6:26 PM Kevin Rushforth
  wrote:

Actually, it's worse than not detecting changes, it's simply not getting the 
right values at all. If I run the program when the system appearance is already 
in Dark mode, it doesn't get the correct values at start up.

-- Kevin

Attachment size limits for the mailing list

[Christopher Schnick]

Hello,

over the last few days I ran into the attachment size limit of this 
mailing list several times, causing the mails to be suspended until they 
are approved. There is also I think another mail still in the moderation 
queue.


I think it would be a good idea to increase the size limit to allow for 
screenshots to be sent, especially since JavaFX is graphical and will 
involve screenshots more than the average JDK mailing list. Of course 
you can also just link to a third-party site where you uploaded the 
image, but that is also not an ideal solution. I think being able to 
send at least a 1920x1080 screenshot would be a good start. That would 
also make the life of the moderators easier.


Best
Christopher Schnick

Re: [External] : Re: Platform preferences theme detection

[Christopher Schnick]

Just tested with JDK 21.0.2 and the behavior is unchanged. I don't have 
an older macOS version <14 to test whether this issue is actually 
specific to 14 or not.


On 12/02/2024 17:49, Kevin Rushforth wrote:
There were changes to AWT in JDK 22 for macOS 14, so it might be worth 
trying JDK 21.0.2. In the mean time, I'll do some testing of this as 
well now that I know it is related to initializing the AWT toolkit.


-- Kevin


On 2/12/2024 8:36 AM, Christopher Schnick wrote:


I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. 
I guess I can try upgrading to JDK 21.0.2, but I will just assume 
that there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to 
quit a JavaFX application via the dock quit operation when it is 
minimized to an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application 
I check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, 
it no longer works. Also, it throws another exception when clicking 
on the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Christopher Schnick]

I am using JDK 21+35 and JavaFX 22-ea+28 to run the project on macOS. I 
guess I can try upgrading to JDK 21.0.2, but I will just assume that 
there haven't been many changes to awt in that time.


Interestingly, I found another issue that occurs when that call to 
|GraphicsEnvironment| is made/not made where it is not possible to quit 
a JavaFX application via the dock quit operation when it is minimized to 
an AWT tray icon. I can file a separate issue for that.


On 12/02/2024 17:20, Kevin Rushforth wrote:
That likely means that initializing the AWT toolkit is interfering 
with this functionality.


I presume you are using a very recent ea build of JavaFX 22. What 
version of JDK are you using?


-- Kevin


On 2/10/2024 9:05 PM, Christopher Schnick wrote:


Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). 
If you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it 
no longer works. Also, it throws another exception when clicking on 
the fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Re: Platform preferences theme detection

[Christopher Schnick]

Well, that is going to be a fun one to debug ... In my application I 
check for a headless environment with 
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices(). If 
you call that one before you initialize your application, the 
preferences detection does no longer update. So if you augment your 
PlatformPreferencesChangedTest application with this main method, it no 
longer works. Also, it throws another exception when clicking on the 
fail button.


|    public static void main(String[] args) {
GraphicsEnvironment.getLocalGraphicsEnvironment().getScreenDevices();
    Application.launch(args);
    }|

On 10/02/2024 18:44, Michael Strauß wrote:

Since I can't reproduce the error on macOS, it's hard to say what
could be causing it.

If you have the chance, maybe you could run the
PlatformPreferencesChangedTest application:
https://github.com/openjdk/jfx/blob/master/tests/manual/events/PlatformPreferencesChangedTest.java

That might rule out that the differences we're seeing have anything to
do with the way we're using the API.


On Sat, Feb 10, 2024 at 6:23 PM Christopher Schnick  wrote:

I checked again, restarted everything, but still the same problem:

Furthermore, I also tested it on my Asahi Fedora Linux with the latest KDE 
Plasma. The preferences values there are all detected correctly, but are never 
updated at runtime when changed in the settings menu.

Detecting successful file drops on macOS

[Christopher Schnick]

Hello,

I'm using macOS Sonoma 14.3 aarch64 and I'm trying to recognize whether 
a file was successfully dropped into finder from the JavaFX application. 
However, the event always reports that it was not accepted. I was under 
the impression that event.isAccepted() should return true if it was 
successfully dropped. This is the reproducer:


|public class DragDrop extends Application {
    @Override
    public void start(Stage primaryStage) throws Exception {
    var file = Files.createTempFile("test", null);

    var r = new Region();
    r.setOnDragDetected(event -> {
    event.setDragDetect(true);
    Dragboard db = r.startDragAndDrop(TransferMode.MOVE);
    var cc = new ClipboardContent();
    cc.putFiles(List.of(file.toFile()));
    db.setContent(cc);
    event.consume();
    });

    r.setOnDragDone(event -> {
    System.out.println("Accepted: " + event.isAccepted());
    System.out.println(event);
    });

    var scene = new Scene(r, 450, 500);
    primaryStage.setScene(scene);
    primaryStage.setTitle("Test");
    primaryStage.show();
    }
}|

|
|

I looked through the documentation of DragEvent but I'm still not really 
sure whether this is a bug. The documentation of DragEvent is a little 
bit light when it comes to behavior of drag events that go to the system 
itself.


Best
Christopher Schnick

Re: Preview features for JavaFX

[Christopher Schnick]

I would add that during the 6 month release cycle, there is usually some 
time to get new features out in an ea release and receive early feedback 
that way. Maybe even in time that it can be incorporated into the next 
release if it is reasonable.


In this concrete case there was no ea build available in maven central 
for 3 months that contained this new feature, so barely anyone used it. 
As an application developer that likes to try out new features, I would 
like to see more frequent maven releases, although I'm not sure how much 
work that is and if it is automated. Even if it is not possible to 
publish every early access release to maven, maybe push a maven release 
out on important points during development of the current release rather 
than in fixed intervals. One such important point would have been the 
release of the platform preferences. I see now that there is another ea 
release available on maven after a gap of 3 months, but that one does 
not contain the fix for Windows color schemes, so any Windows ea user 
will get a nonfunctional feature.


Plus making maybe a small announcement when a new larger feature has 
been released for the first time in early access and linking to the 
appropriate maven release would result in a good real world test 
coverage and discussions with other developers.


Best
Christopher

On 2/6/2024 8:32 AM, Robert Lichtenberger wrote:
Seems like a good idea to me. From an application developer point of 
view I don't care if new parts are super-stable (they never really 
are). If they are marked as preview I'll take that as an additional 
caveat to not rely on API stability, etc.



Robert

Am 06.02.24 um 04:19 schrieb Michael Strauß:

The discussion around the new Platform Preferences API has brought up
a potential area where the API may lack a way to detect whether a
particular preference is supported on a particular operating system
[0].

Discussions like these will invariably come up when new API is
released, and some of the real-world insights may prove to be very
valuable. However, with the current development process, we specify
and implement new features largely without feedback from application
developers. I know that, in principle, developers can join in on the
discussion on this mailing list. But the reality is that GA is the
first time that a new feature gets wider exposure.

All of this makes it very hard for us to ship new features, since we
must be extremely careful to get it right the first time. The JDK uses
incubator modules and preview features to address these challenges. It
seems that OpenJFX will also potentially use an incubator module to
introduce new controls [1].

This is great for modular features, but not so great for new API that
is added to existing infrastructure. Maybe we could add something akin
to preview features to OpenJFX: this could be as easy as documenting
the new API to be in preview, or decorate the new API with a
@PreviewFeature annotation. I don't think that it is necessary to go
beyond simple documentation; in particular, we don't need this to be
integrated with the Java compiler.

Documenting new features to be preview features will enable us to ship
features quicker, and ensure that what we're building is actually
useful in the real world because we can actually go back and improve
aspects of a feature without worrying as much about backwards
compatibility.

In particular, my suggestion is to ship the new Platform Preferences
API as a preview feature for jfx22.


[0] 
https://mail.openjdk.org/pipermail/openjfx-dev/2024-February/045176.html

[1] https://bugs.openjdk.org/browse/JDK-8309381

Re: Platform preferences theme detection

[Christopher Schnick]

Alright, if the accent is not supported yet then almost everything is 
fine I guess. The settings issue is not noticeable as all the updates 
happen very fast.


I want to open my previous question about detecting unsupported colors 
again here. So I assume that for example accent detection is not 
supported on any Linux system and I have not tested yet how widespread 
the support for color scheme detection is on other desktop environments. 
From an application developer's point of view, the platform preferences 
feature loses some appeal if there is no way of enabling a control flow 
like: If the system color is supported use that one, else use the color 
that I manually define somehow.


So it would be nice to either have a relatively simple way of detecting 
which basic color property foreground, background, accent, color scheme 
is actually supported or allow application developers to set the default 
value for that property manually. In this case, I could just set a good 
looking default accent color, which would then be returned on Linux 
systems as that property is not supported yet.


I don't have access to the JBS, I'm not even sure how you get that.

On 2/6/2024 1:26 AM, Michael Strauß wrote:

Hi Christopher!

1) Accent color detection is not yet implemented for Linux/GTK. I 
think this is a fairly recent addition for Ubuntu, probably in version 22.


2) I don't see this behavior on my Ubuntu 20.04 system (need to 
upgrade to 23 and test again). If you have acess to JBS, feel free to 
open a bug ticket to track this issue.



On Mon, Feb 5, 2024 at 10:56 PM Christopher Schnick 
 wrote:


I finally found some time to test the latest ea build and can
confirm that it works now on Windows as expected.

Next, I moved to Linux, more specifically Ubuntu 23.04, and
encountered some issues:
- The accent color detection does not work, i.e. it does not
initially detect the value set in the settings and also does not
change when I modify the accent color in the Ubuntu Settings. I
can see some values changing in the map, however the end result is
still the same
- When opening the Ubuntu Settings application, the entire
platform preferences map is updated with weird values but somehow
changes back immediately after. Maybe it reports the default light
mode colors for a split second when opening the settings?

Once again I do not know whether this is intended or not as there
is no definitive list of which operating systems are supported.
Here is the obligatory preferences map on that system:

Re: Platform preferences theme detection

[Christopher Schnick]

Hello Nir,

I'm not entirely familiar with every ea build, but I'm under the 
impression that the last available 22+ea maven release, which is now 
almost 3 months old, does not contain the platform preferences API and 
also does not contain the kinda important css performance regression fixes.


On 1/30/2024 1:33 PM, Nir Lisker wrote:

Hi Christopher,

Looking at Maven Central, 
https://mvnrepository.com/artifact/org.openjfx/javafx, JavaFX releases 
ea builds there, which I sometimes use myself from Maven/Gradle. 
Version 21 had 6 ea versions, and 22 has 3. The release cycle is 6 
months per final version (aligned with OpenJDK).


- Nir

On Tue, Jan 30, 2024 at 2:18 PM Christopher Schnick 
 wrote:


Alright I will try out the new ea release once the fix is
integrated. Other than that, everything works fine for me so far
with observing colors using the platform-specific strings.

As a side note, I think the community would have caught this issue
earlier if there were more frequent maven releases of ea builds.
As of right now, the only way to properly use recent ea features
is downloading the jars and jmods manually from the jdk.java.net
<http://jdk.java.net> site, which is cumbersome. I don't know how
much of the maven release pipeline is automated and how much work
more frequent ea releases would be, but it would definitely help
with early testing and adoption.

On 1/29/2024 11:09 PM, Michael Strauß wrote:

I see that the names of the platform mappings defined in
WinApplication::getPlatformKeyMappings() are simply wrong
("Windows.UIColor.ForegroundColor" instead of
"Windows.UIColor.Foreground"), so the platform mappings are not
applied to the properties.

That's quite surprising, and it's a change that must have slipped
into the feature at a very late stage during development, so that
it went unnoticed by all reviewers.
I'll file a bug and prepare a fix for this issue.


On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick
 wrote:

Hello Michael,

I took a look at the implementation and tried to find the
issue. From what I can see, the mappings returned are correct:



but it seems like they are somehow not applied the
PreferencesProperties:

Let me know whether I can help with anything to debug this issue.

Re: Platform preferences theme detection

[Christopher Schnick]

Alright I will try out the new ea release once the fix is integrated. 
Other than that, everything works fine for me so far with observing 
colors using the platform-specific strings.


As a side note, I think the community would have caught this issue 
earlier if there were more frequent maven releases of ea builds. As of 
right now, the only way to properly use recent ea features is 
downloading the jars and jmods manually from the jdk.java.net site, 
which is cumbersome. I don't know how much of the maven release pipeline 
is automated and how much work more frequent ea releases would be, but 
it would definitely help with early testing and adoption.


On 1/29/2024 11:09 PM, Michael Strauß wrote:
I see that the names of the platform mappings defined in 
WinApplication::getPlatformKeyMappings() are simply wrong 
("Windows.UIColor.ForegroundColor" instead of 
"Windows.UIColor.Foreground"), so the platform mappings are not 
applied to the properties.


That's quite surprising, and it's a change that must have slipped into 
the feature at a very late stage during development, so that it went 
unnoticed by all reviewers.

I'll file a bug and prepare a fix for this issue.


On Mon, Jan 29, 2024 at 10:45 PM Christopher Schnick 
 wrote:


Hello Michael,

I took a look at the implementation and tried to find the issue.
From what I can see, the mappings returned are correct:



but it seems like they are somehow not applied the
PreferencesProperties:

Let me know whether I can help with anything to debug this issue.

Re: Platform preferences theme detection

[Christopher Schnick]

Hello Michael,

I took a look at the implementation and tried to find the issue. From 
what I can see, the mappings returned are correct:




but it seems like they are somehow not applied the PreferencesProperties:

Let me know whether I can help with anything to debug this issue.

On 1/29/2024 10:37 PM, Michael Strauß wrote:

Hi Christopher!


- Should this feature work in that ea version?

Yes.



- Is Windows 10 supported by the color scheme detection?

Color scheme detection should be supported on Windows 10 beginning
with build 10240.



- The documentation says that LIGHT is returned in case theme the
detection is not supported. But I guess there is no way to find out
whether querying that property is supported on the current system? It
might be useful in some circumstances to adapt the behavior when we know
that this is not supported.

There is no way to directly query whether any of the
platform-independent properties (colorScheme, backgroundColor,
foregroundColor, accentColor) are supported by the current OS.
You can check whether the platform-dependent mappings (for example,
"Windows.UIColor.Background") are contained in the map, which will
only be the case if supported by the OS.



- The documentation mentions that some preferences might not be
available on the current system. Does that mean that if they are
available, they are also observable? Or might it be possible that a
certain setting is available but does not support dynamically updating
at runtime and cannot be observed?

If you see a mapping for a preference, it should also be updated
automatically if the corresponding OS setting is changed.

Do you see the mappings for "Windows.UIColor.Background" and
"Windows.UIColor.Foreground" in the map returned by
Platform.getPreferences()?
The color scheme value is derived from these colors. If the mappings
are not present, something unexpected is happening.



On Mon, Jan 29, 2024 at 9:23 PM Christopher Schnick  wrote:

Hello,

I just tried out the new 22-ea+27 build to see whether we can utilize
some of the new features, particularly the platform preferences API, to
replace the libraryhttps://github.com/Dansoftowner/jSystemThemeDetector
that we are currently using for theme detection.

I'm running this on Windows 10 with the latest updates and the color
scheme always reports LIGHT, even when dark mode is enabled in the
settings. The observable value also does not update when the value
changes in the settings. Obviously I have a few questions here:
- Should this feature work in that ea version?
- Is Windows 10 supported by the color scheme detection?
- The documentation says that LIGHT is returned in case theme the
detection is not supported. But I guess there is no way to find out
whether querying that property is supported on the current system? It
might be useful in some circumstances to adapt the behavior when we know
that this is not supported.
- The documentation mentions that some preferences might not be
available on the current system. Does that mean that if they are
available, they are also observable? Or might it be possible that a
certain setting is available but does not support dynamically updating
at runtime and cannot be observed?

Best regards
Christopher

Platform preferences theme detection

[Christopher Schnick]

Hello,

I just tried out the new 22-ea+27 build to see whether we can utilize 
some of the new features, particularly the platform preferences API, to 
replace the library https://github.com/Dansoftowner/jSystemThemeDetector 
that we are currently using for theme detection.


I'm running this on Windows 10 with the latest updates and the color 
scheme always reports LIGHT, even when dark mode is enabled in the 
settings. The observable value also does not update when the value 
changes in the settings. Obviously I have a few questions here:

- Should this feature work in that ea version?
- Is Windows 10 supported by the color scheme detection?
- The documentation says that LIGHT is returned in case theme the 
detection is not supported. But I guess there is no way to find out 
whether querying that property is supported on the current system? It 
might be useful in some circumstances to adapt the behavior when we know 
that this is not supported.
- The documentation mentions that some preferences might not be 
available on the current system. Does that mean that if they are 
available, they are also observable? Or might it be possible that a 
certain setting is available but does not support dynamically updating 
at runtime and cannot be observed?


Best regards
Christopher

Re: Performance Regression in 21 - CSS

[Christopher Schnick]

Hello,

I just tested this with our JavaFX application and can confirm that 
there are massive differences. It takes around 1-2 seconds to completely 
apply all application stylesheets in JavaFX 20 but takes around 6-7 
seconds in JavaFX 21.


On 12/31/2023 3:00 PM, Florian Kirmaier wrote:

Hi Everyone,

Sorry for the delay - but I couldn’t find the time to extract the 
TestApplication for this bug.
Luckily, I found another application, which is also open source, which 
is affected by the application.


I'm speaking about https://www.jfx-central.com/ - both the desktop and 
web versions are affected.
I’ve seen a performance deterioration of 10x when switching pages when 
using JavaFX21 compared to JavaFX20.


I’ve created a ticket with further instructions on how to test it:
https://bugs.openjdk.org/browse/JDK-8322795

Greetings

Florian Kirmaier

On Fri, 27 Oct 2023 at 21:31, Andy Goryachev 
 wrote:


Please create a ticket, Florian.  Would it be possible to profile
the application when scrolling?

Thank you

-andy

*From: *openjfx-dev  on behalf of
Florian Kirmaier 
*Date: *Friday, October 27, 2023 at 04:20
*To: *openjfx-...@openjdk.java.net 
*Subject: *Performance Regression in 21 - CSS

Hi everyone,

I've noticed that some parts of one of my applications is
significantly slower with 21. It's fast with 20.
The application heavily uses (and reuses) TextFlow with a Cell
pattern.
When I scroll, it is smooth with 20, but has big freezes with 21.

I've tried all the commits that happened in between, and
pin-pointed it down to the following:
ticket: https://bugs.openjdk.org/browse/JDK-8304959
PR: https://github.com/openjdk/jfx/pull/1070
commit:

https://github.com/openjdk/jfx21u/commit/3fa02ee96a6dadbc20cacbf399a2d65df708eee1


According to the description and the discussion in the PR - this
wasn't supposed to change any performance.
Is this regression known?
Otherwise, I should create a ticket for it.

Greetings Florian

Re: ToolBar rendering bug

[Christopher Schnick]

Alright, I will see what I can do. I was not able to reproduce it every 
time, so I hope it doesn't get too tricky.


On 11/16/2023 12:20 AM, Andy Goryachev wrote:


Dear Christopher:

You application does look nice!

Please understand that without an SCCE, it would be nearly impossible 
for us to do anything.  I can help in creating a bug, but a minimal 
reproducible example is absolute must.


-andy

*From: *openjfx-dev  on behalf of 
Christopher Schnick 

*Date: *Monday, November 13, 2023 at 17:46
*To: *openjfx-dev@openjdk.org 
*Subject: *ToolBar rendering bug

Hello,

I recently stumbled upon a weird rendering issue and managed to
reproduce it, at least inside my own application:
https://www.youtube.com/watch?v=BcMVIOkk-84 . Sadly I don't have the
time to create a minimal reproducible example right now.

I suspect the problem occurs when a ToolBar is width-constrained and has
to wrap some of its content. If a node in the toolbar that is not
wrapped changes its width but no wrapping change occurs, as shown in the
video when I try to open the search bar, the calculations break and
somehow corrupt all nodes to the right of it.

The application is running with JavaFX 21.0.1 on Windows 10.

Best regards, Christopher

ToolBar rendering bug

[Christopher Schnick]

Hello,

I recently stumbled upon a weird rendering issue and managed to 
reproduce it, at least inside my own application: 
https://www.youtube.com/watch?v=BcMVIOkk-84 . Sadly I don't have the 
time to create a minimal reproducible example right now.


I suspect the problem occurs when a ToolBar is width-constrained and has 
to wrap some of its content. If a node in the toolbar that is not 
wrapped changes its width but no wrapping change occurs, as shown in the 
video when I try to open the search bar, the calculations break and 
somehow corrupt all nodes to the right of it.


The application is running with JavaFX 21.0.1 on Windows 10.

Best regards, Christopher

Re: Several GTK issues on latest Ubuntu release

[Christopher Schnick]

I tested on Wayland and X.org, and they both show exactly the same behavior.

(Apologies if this mail somehow breaks the mailing list chain, the 
digest mode makes it hard to reply to some mails)


On 10/25/2023 5:21 PM, openjfx-dev-requ...@openjdk.org wrote:

Question for the original poster of this thread: Are you running the
Wayland server or the X.org server?

-- Kevin


On 10/24/2023 5:53 PM, Thiago Milczarek Say?o wrote:

I suspect something changed on the window manager (mutter in the case
of default Ubuntu/gnome).

One problem is that focusing the window is restoring it's state - so
if you focus a maximized window the window manager restores it - looks
like a bug.

In the case of JavaFX the native side is calling realize on the window
which causes the underlying window to be created (X Window - the X11
window) and I suspect its the source of the problem. Might still be a
bug on the window manager, but the PR mentioned let's GTK realize the
window first, so it doesn't change the "natural" order expected by GTK.

I confirm that it fixes the window sizing problem reported on the issue.

Not sure about other problems, but I suspect they might be gone after
the fix (except for the state after focus).

Thiago






Em seg., 23 de out. de 2023 11:48, Christopher Schnick
  escreveu:

 That is good to know that this issue is already being worked on.
 From the description of
 https://bugs.openjdk.org/browse/JDK-8316423, this issue is only
 tracked as affecting secondary stages? At least in our case it
 affects the primary stage as well, i.e. the one that is supplied
 via Application.start. Also, in this case it's not really about
 the scene dimensions, the stage doesn't even apply its own
 dimensions that were explicitly set before.

 On 10/23/2023 4:39 PM, Thiago Milczarek Say?o wrote:

 Forgot to mention: except for the system tray, I'm not looking
 into that.

 Em seg., 23 de out. de 2023 11:36, Thiago Milczarek Say?o
   escreveu:

 Hi Cristopher,

 https://github.com/openjdk/jfx/pull/1249

 We noticed it and I'm working on a fix.

 There's one issue that is probably a mutter bug:

 https://gitlab.gnome.org/GNOME/mutter/-/issues/3092

 -- Thiago

 Em seg., 23 de out. de 2023 10:05, Christopher Schnick
   escreveu:

 Hello,

 a user of our application xpipe
 <https://github.com/xpipe-io/xpipe>  reported several
 issues after upgrading their Ubuntu version and I
 investigated them myself. I want to note here that these
 issues are exclusive to new Ubuntu versions. I did not
 observe any of them on slightly older Ubuntu versions or
 other Gnome-based desktop environments. I don't know
 exactly which versions are affected, but 22.04 works fine
 and Ubuntu 23.10 does not.

 I'm sorry that I'm not able to create fully reproducible
 examples or dig deeper into the causes here, but I'm very
 constrained on time right now. For reproduction, I just
 installed a new default Ubuntu 23.10 VM and launched the
 JavaFX 21 application straight out of the box.

 The first issue is that windows do not retain their
 information when being hidden and then shown again. I.e.
 after being shown for the second time, they will have
 tiny dimensions and an GTK error is printed to stderr
 about height < 0. For now I temporarily resolve this by
 doing the following, which somehow fixes the issue:

 stage.show();

 ??? // Due to some weird GTK bug, we have to set
 these sizes every time we show a window again even though
 they have been previously set
 ??? stage.setX(stage.getX());
 ??? stage.setY(stage.getY());
 ??? stage.setWidth(stage.getWidth());
 stage.setHeight(stage.getHeight());

 Furthermore, while this is technically not purely JavaFX
 related, there is also a total freeze of the platform
 thread when it calls javax.swing.UIManager.setLookAndFeel
 as it gets stuck in some GTK implementation method. This
 is called by the fxtrayicon library, which calls this
 method here
 
<https://github.com/dustinkredmond/FXTrayIcon/blob/81c99a7357d8f48d9547c0bdb54b848041ce67c6/src/main/java/com/dustinredmond/fxtrayicon/FXTrayIcon.java#L923>.
 Since there is no native JavaFX tray integration, calling
 these awt/swing related methods is quite important for
 applications trying to use the system tray. This was a
 very unfortunate issue for us as it caused applications
 to not start up at all on affecte

Re: Several GTK issues on latest Ubuntu release

[Christopher Schnick]

I don't think any of the existing bug tracker issues apply to this 
problem though. The reason I also posted it in here is that this issue 
is exclusive to the JavaFX platform thread. If this method is invoked in 
any other thread, it works fine. I investigated a bit further on this 
issue, I got the stack trace of where it gets stuck:


    native_get_gtk_setting:-1, GTKEngine (com.sun.java.swing.plaf.gtk)
    getSetting:633, GTKEngine (com.sun.java.swing.plaf.gtk)
    getGTKStyleFactory:1562, GTKLookAndFeel 
(com.sun.java.swing.plaf.gtk)

    loadStyles:1548, GTKLookAndFeel (com.sun.java.swing.plaf.gtk)
    initialize:1441, GTKLookAndFeel (com.sun.java.swing.plaf.gtk)
    setLookAndFeel:590, UIManager (javax.swing)
    setLookAndFeel:637, UIManager (javax.swing)
    attemptSetSystemLookAndFeel:690, FXTrayIcon 
(com.dustinredmond.fxtrayicon)

    :242, FXTrayIcon (com.dustinredmond.fxtrayicon)
    :640, FXTrayIcon (com.dustinredmond.fxtrayicon)
    build:630, FXTrayIcon$Builder (com.dustinredmond.fxtrayicon)
    :59, AppTray (io.xpipe.app.core)
    init:69, AppTray (io.xpipe.app.core)
    lambda$onSwitchTo$0:26, TrayMode (io.xpipe.app.core.mode)
    run:-1, TrayMode$$Lambda/0x80724178 
(io.xpipe.app.core.mode)
    lambda$runLaterIfNeededBlocking$1:319, PlatformThread 
(io.xpipe.app.fxcomps.util)
    run:-1, PlatformThread$$Lambda/0x80470d70 
(io.xpipe.app.fxcomps.util)
    lambda$runLaterIfNeededBlocking$2:328, PlatformThread 
(io.xpipe.app.fxcomps.util)
    run:-1, PlatformThread$$Lambda/0x80470f90 
(io.xpipe.app.fxcomps.util)
    lambda$runLater$10:456, PlatformImpl 
(com.sun.javafx.application)
    run:-1, PlatformImpl$$Lambda/0x80417c38 
(com.sun.javafx.application)

    executePrivileged:778, AccessController (java.security)
    doPrivileged:400, AccessController (java.security)
    lambda$runLater$11:455, PlatformImpl (com.sun.javafx.application)
    run:-1, PlatformImpl$$Lambda/0x804177e8 
(com.sun.javafx.application)

    run:95, InvokeLaterDispatcher$Future (com.sun.glass.ui)
    _runLoop:-1, GtkApplication (com.sun.glass.ui.gtk)
    lambda$runLoop$10:263, GtkApplication (com.sun.glass.ui.gtk)
    run:-1, GtkApplication$$Lambda/0x802b8c38 
(com.sun.glass.ui.gtk)

    runWith:1596, Thread (java.lang)
    run:1583, Thread (java.lang)

You can call this method in the first line in the Application.start 
method and it will also get stuck, so it doesn't really matter from 
where it gets called as long as it is the JavaFX platform thread.


On 10/23/2023 6:18 PM, Philip Race wrote:
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 FX.
In fact it is used for only 2 things and only one of those can matter 
in your app,
and that is that the Swing GTK L uses it to get the rendering of GTK 
themes.
So if you weren't using the GTK L then a Swing app would likely not 
even load GTK.
But for a mixed FX + Swing app then of course it will still be loaded 
by FX.


-phil.



On 10/23/23 7:48 AM, Christopher Schnick wrote:


That is good to know that this issue is already being worked on. From 
the description of https://bugs.openjdk.org/browse/JDK-8316423, this 
issue is only tracked as affecting secondary stages? At least in our 
case it affects the primary stage as well, i.e. the one that is 
supplied via Application.start. Also, in this case it's not really 
about the scene dimensions, the stage doesn't even apply its own 
dimensions that were explicitly set before.


On 10/23/2023 4:39 PM, Thiago Milczarek Sayão wrote:
Forgot to mention: except for the system tray, I'm not looking into 
that.


Em seg., 23 de out. de 2023 11:36, Thiago Milczarek Sayão 
 escreveu:


Hi Cristopher,

https://github.com/openjdk/jfx/pull/1249

We noticed it and I'm working on a fix.

There's one issue that is probably a mutter bug:

https://gitlab.gnome.org/GNOME/mutter/-/issues/3092

-- Thiago

Em seg., 23 de out. de 2023 10:05, Christopher Schnick
 escreveu:

Hello,

a user of our application xpipe
<https://github.com/xpipe-io/xpipe> reported several issues
after upgrading their Ubuntu version and I investigated them
myself. I want to note here that these issues are exclusive
to new Ubuntu versions. I did not observe any of them on
slightly older Ubuntu versions or other Gnome-based desktop
environments. I don't know exactly which versions are
affected, but 22.04 works fine and Ubuntu 23.10 does not.

I'm sorry that I'm no

Re: Several GTK issues on latest Ubuntu release

[Christopher Schnick]

That is good to know that this issue is already being worked on. From 
the description of https://bugs.openjdk.org/browse/JDK-8316423, this 
issue is only tracked as affecting secondary stages? At least in our 
case it affects the primary stage as well, i.e. the one that is supplied 
via Application.start. Also, in this case it's not really about the 
scene dimensions, the stage doesn't even apply its own dimensions that 
were explicitly set before.


On 10/23/2023 4:39 PM, Thiago Milczarek Sayão wrote:

Forgot to mention: except for the system tray, I'm not looking into that.

Em seg., 23 de out. de 2023 11:36, Thiago Milczarek Sayão 
 escreveu:


Hi Cristopher,

https://github.com/openjdk/jfx/pull/1249

We noticed it and I'm working on a fix.

There's one issue that is probably a mutter bug:

https://gitlab.gnome.org/GNOME/mutter/-/issues/3092

-- Thiago

Em seg., 23 de out. de 2023 10:05, Christopher Schnick
 escreveu:

Hello,

a user of our application xpipe
<https://github.com/xpipe-io/xpipe> reported several issues
after upgrading their Ubuntu version and I investigated them
myself. I want to note here that these issues are exclusive to
new Ubuntu versions. I did not observe any of them on slightly
older Ubuntu versions or other Gnome-based desktop
environments. I don't know exactly which versions are
affected, but 22.04 works fine and Ubuntu 23.10 does not.

I'm sorry that I'm not able to create fully reproducible
examples or dig deeper into the causes here, but I'm very
constrained on time right now. For reproduction, I just
installed a new default Ubuntu 23.10 VM and launched the
JavaFX 21 application straight out of the box.

The first issue is that windows do not retain their
information when being hidden and then shown again. I.e. after
being shown for the second time, they will have tiny
dimensions and an GTK error is printed to stderr about height
< 0. For now I temporarily resolve this by doing the
following, which somehow fixes the issue:

    stage.show();

    // Due to some weird GTK bug, we have to set these
sizes every time we show a window again even though they have
been previously set
    stage.setX(stage.getX());
    stage.setY(stage.getY());
    stage.setWidth(stage.getWidth());
    stage.setHeight(stage.getHeight());

Furthermore, while this is technically not purely JavaFX
related, there is also a total freeze of the platform thread
when it calls javax.swing.UIManager.setLookAndFeel as it gets
stuck in some GTK implementation method. This is called by the
fxtrayicon library, which calls this method here

<https://github.com/dustinkredmond/FXTrayIcon/blob/81c99a7357d8f48d9547c0bdb54b848041ce67c6/src/main/java/com/dustinredmond/fxtrayicon/FXTrayIcon.java#L923>.
Since there is no native JavaFX tray integration, calling
these awt/swing related methods is quite important for
applications trying to use the system tray. This was a very
unfortunate issue for us as it caused applications to not
start up at all on affected systems.
I wasn't able to compare the behavior to Ubuntu 22.04 as
SystemTray.isSupported() returns false on Ubuntu 22.04 but
returns true on Ubuntu 23.10. Should this even return true on
Ubuntu now or is this a bug?

Again, these issues only occur on the very latest Ubuntu
release. I have tested on a lot of other different distros,
old and new, and they all worked flawlessly.

Best regards, Christopher

Several GTK issues on latest Ubuntu release

[Christopher Schnick]

Hello,

a user of our application xpipe  
reported several issues after upgrading their Ubuntu version and I 
investigated them myself. I want to note here that these issues are 
exclusive to new Ubuntu versions. I did not observe any of them on 
slightly older Ubuntu versions or other Gnome-based desktop 
environments. I don't know exactly which versions are affected, but 
22.04 works fine and Ubuntu 23.10 does not.


I'm sorry that I'm not able to create fully reproducible examples or dig 
deeper into the causes here, but I'm very constrained on time right now. 
For reproduction, I just installed a new default Ubuntu 23.10 VM and 
launched the JavaFX 21 application straight out of the box.


The first issue is that windows do not retain their information when 
being hidden and then shown again. I.e. after being shown for the second 
time, they will have tiny dimensions and an GTK error is printed to 
stderr about height < 0. For now I temporarily resolve this by doing the 
following, which somehow fixes the issue:


    stage.show();

    // Due to some weird GTK bug, we have to set these sizes every 
time we show a window again even though they have been previously set

    stage.setX(stage.getX());
    stage.setY(stage.getY());
    stage.setWidth(stage.getWidth());
    stage.setHeight(stage.getHeight());

Furthermore, while this is technically not purely JavaFX related, there 
is also a total freeze of the platform thread when it calls 
javax.swing.UIManager.setLookAndFeel as it gets stuck in some GTK 
implementation method. This is called by the fxtrayicon library, which 
calls this method here 
. 
Since there is no native JavaFX tray integration, calling these 
awt/swing related methods is quite important for applications trying to 
use the system tray. This was a very unfortunate issue for us as it 
caused applications to not start up at all on affected systems.
I wasn't able to compare the behavior to Ubuntu 22.04 as 
SystemTray.isSupported() returns false on Ubuntu 22.04 but returns true 
on Ubuntu 23.10. Should this even return true on Ubuntu now or is this a 
bug?


Again, these issues only occur on the very latest Ubuntu release. I have 
tested on a lot of other different distros, old and new, and they all 
worked flawlessly.


Best regards, Christopher