RFR: 8354943: [Linux] Simplify and update glass gtk backend: window sizing, positioning, and state management issues [v9]

[Martin Fox]

On Sat, 26 Apr 2025 19:01:13 GMT, Thiago Milczarek Sayao <tsayao at 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. It embraces the asynchronous nature of X11 by reporting geometry changes only upon receiving a configure event, rather than immediately as before. This is because it merely requests changes from the window manager, which may or may not honor them. However, it still reports changes immediately in certain special cases, such as when the window has not yet been realized (i.e., when the window has not actually been created yet). One scenario where this behavior is evident is when we request the window to move to position (0, 0), but the window manager instead places it in the top-right corner where panels converge.
>> 2. FullScreen now keeps track of geometry changes and apply them on restore as documented on Stage.java. No geometry changes affects the FullScreen state;
>> 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 also provided but I would prefer to move it's functionality to monkey tester:
>> `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)
>> 2. [[Linux] Intermittent test failure in IconifyTest.ca...
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove old comment

tests/system/src/test/java/test/robot/javafx/stage/StageAttributesTest.java line 312:

> 310:     @ParameterizedTest(name = PARAMETERIZED_TEST_DISPLAY)
> 311:     @EnumSource(names = {"DECORATED", "UNDECORATED"})
> 312:     void testStageStatePrecedenceOrderIconifiedMaximizedBeforeShow(StageStyle stageStyle) throws InterruptedException {

The precedence rules written into the spec are very problematic and it would be a bear to implement them. For example, if you attempt to maximize an iconified stage on Windows it will de-iconify. Making it stay iconified and maximize later would take real effort. Maximizing an iconified stage on Mac does nothing (glass loses the maximized state) and fixing that would also take a lot of work. I really think our time would be better spent leaving things as-is and updating the spec.

I don't think the API calls for maximizing and iconifying the stage are useful to begin with. These are features provided to users so they can manager their desktop real estate. There's not a lot of compelling use cases for apps to do this.

-------------

PR Review Comment: https://git.openjdk.org/jfx/pull/1789#discussion_r2067143320