On Thu, 5 Nov 2026 10:23:17 GMT, Thiago Milczarek Sayao <[email protected]> wrote:
>> This is a continuation to >> [JDK-8236651](https://bugs.openjdk.org/browse/JDK-8236651) and it aims to >> stabilize the linux glass gtk backend. >> >> It refactors the Glass GTK implementation with a primary focus on window >> sizing, positioning, and state management, addressing a number of >> long-standing issues. >> >> Previously, three separate context classes existed, two of which were used >> for Java Web Start and Applets. These have been unified, as they are no >> longer required. >> >> Additional tests have been introduced to improve coverage. Some tests >> produced different results depending on the StageStyle, so they have been >> converted to use `@ParameterizedTest` to exercise multiple styles. >> >> Although the primary focus is XWayland, the changes have also been verified >> to work correctly on Xorg. >> >> This replaces #1789. It removes the use of GdkWindow in favor of GtkWindow, >> reducing risk and simplifying the review process while preserving the same >> set of bug fixes. Additionally, #2025 requires a `GtkWindow` to be used when >> setting the parent of the file chooser dialog. >> >> To show debug messages, build with `-PCONF=DebugNative` and run with >> `-Djdk.gtk.verbose=true`. Log categories can be passed with >> `-Dglass.gtk.logCategories=CATEGORY` >> >> `CATEGORY` can be one or more of: >> - all >> - size >> - position >> - focus >> - state >> - lifecycle >> - input >> - dialog >> >> Multiple categories can be specified by separating them with commas (e.g. >> size,focus,input). >> >> A manual test is provided: >> `java @build/run.args tests/manual/stage/TestStage.java` >> >> When a window property is set, it is reported immediately. However, once it >> reaches the native Glass layer, it may be adjusted or rejected, causing the >> property to be updated again. Introducing a delay helps ensure the final >> state has been applied before it is verified. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Thiago Milczarek Sayao has updated the pull request with a new target base > due to a merge or a rebase. The pull request now contains 58 commits: > > - Merge branch 'master' into 8354943_v2 > - Revert "[Linux] Robot: screencast restore token is wrongly assumed to be a > UUID" > > This reverts commit 6230bca16d5f80e776b2c53e81a5d768422949e0. > - Revert "[Linux] Robot: screencast restore token is wrongly assumed to be a > UUID" > > This reverts commit fa58a4e923d78f8aef6b84395e4a2318ab37bb3a. > - Merge branch '8396109' into 8354943_v2 > - [Linux] Robot: screencast restore token is wrongly assumed to be a UUID > - [Linux] Robot: screencast restore token is wrongly assumed to be a UUID > - glass_window_ime.cpp: check for null jview > glass_window.h: review suggestions > glass_general.h: wrap log on a do {} while(0) > - - Ungrab focus when hiding the window, so IME does not try to use it after > closed > - - Avoid null title > - Nested changes can happen if java reacts to the change > - Extended stages with no view, call base. > - Merge branch 'master' into 8354943_v2 > > # Conflicts: > # tests/system/src/test/java/test/util/Util.java > - ... and 48 more: https://git.openjdk.org/jfx/compare/0165faf6...47605b4a Got another question to the implementation, and also when testing the change I found one problem which is a discrepancy in behavior in Linux, attached a reproducer to it. In short, when a Stage has called `setResizable(false)` and then we request it to maximize or fullscren by `setMaximize(true)`/`setFullScreen(true)` the latter request is ignored on Linux. This doesn't happen on Windows. I think `setResizable` was just supposed to block UI-based resizing, but programmatically resizing the Stage should still work. For the record, I'm pretty sure this behaved like this also before your changes, but I figured I'd mention it. I think it's a problem somewhere in `glass_window.cpp` in `process_map` with window constraints, but I didn't dig too deep into it. Reproducer: import javafx.application.Application; import javafx.application.Platform; import javafx.scene.Group; import javafx.scene.Scene; import javafx.stage.Stage; public class NonResizableMaximizeBug extends Application { @Override public void start(Stage stage) { stage.setScene(new Scene(new Group())); stage.setTitle("FixedSizeMaximizeBug"); stage.setWidth(640); stage.setHeight(480); stage.setResizable(false); stage.setMaximized(true); stage.show(); } public static void main(String[] args) { launch(args); } } modules/javafx.graphics/src/main/java/com/sun/glass/ui/gtk/GtkWindow.java line 133: > 131: protected boolean _minimize(long ptr, boolean minimize) { > 132: minimizeImpl(ptr, minimize); > 133: notifyStateChanged(WindowEvent.MINIMIZE); I have a question about this part - `notifyStateChanged` also internally called `Window.notifyResize` to update the Window's internal state immediately. At this point I think the state change relies on GTK processing the event loop. Shouldn't at least the `notifyResize` call still remain here just to keep Window's internal state up-to-date? ------------- PR Review: https://git.openjdk.org/jfx/pull/2139#pullrequestreview-5738908147 PR Review Comment: https://git.openjdk.org/jfx/pull/2139#discussion_r4444687732
