gtk3 menu glitch

[AiyionPrime]

Running the application using gtk3 in Linux works, but has strange effects on the menubar.

Starting with OpenJDK 11 GTK3 is enabled by default; the gtk2-startparameter mentioned in the readme does help with this, though I did not receive warnings or errors on the commandline.

Finally found it. This is the upstream bug.

Running the application in gtk2 does apparently work, as no gtk3-exclusive features were used in this project:

java -Djdk.gtk.version=2 -jar minimax_simulator-2.0.0-jar-with-dependencies.jar

But as this project requires JDK11, a hint for (Open?)JDK11 users might be worthwhile.

I currently have no way of reproducing this on other setups.

[prohde]

It seems like this is an issue with a particular window manager. I can not reproduce it on my setups (OpenJDK 11.0.9.1 @ Ubuntu 18.04/20.04). I'd suggest to mention the use of the above command to run the application under those circumstances in the readme as well.

[AiyionPrime]

It's appears to be an issue with every window manager that crops the top bar of applications; or in case of i3 even adds its own. I elaborated further upstream; it's not something the simulator should need to fix, imho.

[MasFlam]

Nobody is cropping the top bar, they are just not adding it to the window. The program wouldn't be able to determine in a standardized way its decoration bar height anyway afaik. Window managers are standard compliant; the issue lies on JavaFX's side which most likely expects some WM<->client protocol which isn't implemented by any of the major tiling WMs, and it's annoying as hell. I might try to dive deeper into OpenJFX code, who knows maybe I'll get somewhere.

[AiyionPrime]

Good luck.

[prohde]

Are there any specific setups where this is happening?

I still cannot reproduce the problem on my machine. OS: Ubuntu 20.04 Java: OpenJDK 11.0.14 JavaFX: 11.26 WM: Gnome

[AiyionPrime]

The upstream-bug linked above contains more descriptions than mine:

OpenJDK14.0.2, i3 4.19, Linux 5.9.11-arch2-1

Thanks @io7m for providing the video. Have been searching for this for about an hour now, and not getting it reproduced > properly was driving me nuts -.-'

Originally posted by @AiyionPrime in https://github.com/javafxports/openjdk-jfx/issues/546#issuecomment-740701354

[MasFlam]

Status update: I traced down the culprit to Scene#getY() returning non-0 when it in fact should return 0 in my case. (I don't shift my scene inside of the window). This results in adding an unnecessary 28 (at least in my case) in Node#localToScreen(double localX, double localY, double localZ) to maxY and minY of the MenuButton's Bounds, (MenuBar uses MenuButton under the hood) which in turn shifts the Y coordinate of the ContextMenu that appears when the MenuButton is rolled out. I don't know yet why Scene#getY() returns an incorrect number though. I'm also not sure where the number 28 could come from. for comparison, a Button's/MenuButton's default height for me is 24 pixels.

[MasFlam]

Are there any specific setups where this is happening?

Mine is dwm running on Debian. It seems all the major tiling WMs experience this issue though.

[MasFlam]

Update 2: The Y coordinate of my scene becomes 28 when the stage it is assigned to is shown. Some event is synthesized there and during the handling of it the scene's coordinates are adjusted, though I don't understand yet the reasoning behind that. Too tired now to investigate further, will be back tomorrow :)

[AiyionPrime]

I think your updates on the hunt are better suited for the upstream bug. Here your audience are 'only' prohde and me, of which neither has the time to fix the upstream bug. Hotfixing it downstream is out of scope for this project, as the sra seems to not evene have time to monitor PRs on this project.

Link is above, happy hunting!

[MasFlam]

The upstream issue is archived, I cannot reply to it :/ but you're right. Maybe there is one on the openjdk/jfx repo, and if not I probably should open one.

There seems to be a similar one here