On Thu, 1 May 2025 14:50:15 GMT, Thiago Milczarek Sayao <tsa...@openjdk.org> 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. >> >> >> Overall, it has been made more robust within its scope, particularly in >> terms of sizing, positioning, and state management. >> >> List of changes: >> 1. Use GDK for creating Windows. Since we paint directly to the underlying >> XWindow, creating a GtkWidget for the window is unnecessary and results in >> unused GTK resources. Additionally, avoiding the use of a GtkWidget >> eliminates the need for workarounds caused by conflicting GTK behavior—such >> as setting the initial window state, position, or size. >> 2. It aligns with X11's asynchronous behavior by reporting geometry changes >> only upon receiving a configure event, since requests to the window manager >> aren't guaranteed to be honored. However, changes are still reported >> immediately in special cases, such as before the window is realized. For >> example, a request to move the window to (0, 0) might be overridden by the >> window manager, placing it in the top-right corner instead. >> 3. States (fullscreen, maximized and iconify) are now reported back to Java >> when it actually happens rather than immediately (except when not realized); >> 4. When a window is maximized, it will ignore geometry changes and restore >> to the geometry it had prior to being maximized. After some testing, I >> believe this is the best behavior for platform compatibility; >> 5. Unifies the WindowContext class: previously, there were three separate >> classes—two of which (for applets and Java Web Start) were removed, leaving >> only one. However, the supporting infrastructure was still there partially. >> [Unify WindowContext in >> glass-gtk](https://bugs.openjdk.org/browse/JDK-8305768) >> 6. Tests were added and re-enabled to ensure everything works correctly. The >> stage tests now cover various StageStyle configurations, as I found that >> `DECORATED` stages often behave differently from `UNDECORATED` or `UTILITY` >> stages; >> 7. Added Logs for debugging. Enable it with ` -PCONF=DebugNative`; >> 8. Old work-arounds dating back to Ubuntu 16.04 with Compiz were removed. >> >> A simple manual test is provided: >> `java @build/run.args tests/manual/stage/TestStage.java ` >> >> >> List of fixed issues: >> >> 1. [[Linux] Stage.setMaximized() before show() does not >> persist](https://bugs.openjdk.org/browse/JDK-8316425) >> 3. [[Linux] Intermittent test failure in >> IconifyTest.canIconifyDecoratedStage](https://bugs.openjdk.org/browse/JDK-831689... > > Thiago Milczarek Sayao has updated the pull request incrementally with one > additional commit since the last revision: > > Fix test on SizingTest modules/javafx.graphics/src/main/native-glass/gtk/GlassApplication.cpp line 486: > 484: case GDK_PROPERTY_NOTIFY: > 485: ctx->process_property_notify(&event->property); > 486: gtk_main_do_event(event); Some event types first call respective `ctx->process` and then `gtk_main_do_event`, while others do it the other way around. Is there a specific reason why? modules/javafx.graphics/src/main/native-glass/gtk/GlassRobot.cpp line 22: > 20: * > 21: * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA > 22: * or visit www.oracle.com if you need additiFonal information or have any Coincidental change in copyright header modules/javafx.graphics/src/main/native-glass/gtk/glass_general.h line 251: > 249: #define LOG5(msg, param1, param2, param3, param4, param5) {printf(msg, > param1, param2, param3, param4, param5);fflush(stdout);} > 250: #define LOG6(msg, param1, param2, param3, param4, param5, param6) > {printf(msg, param1, param2, param3, param4, param5, param6);fflush(stdout);} > 251: #define LOG10(msg, param1, param2, param3, param4, param5, param6, > param7, param8, param9, param10) \ Instead of adding more `LOG*` macros consider replacing them with `#define LOG(...) { printf(__VA_ARGS__); fflush(stdout); }` Eventually I would accept filing a separate change for improving this if we don't have one already. Seems like the `ERROR` macros below could also be improved in this way. ------------- PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071271567 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071440205 PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2071479393
