RFR: 8260528: Clean glass-gtk sizing and positioning code [v31]

[Kevin Rushforth]

On Thu, 8 Dec 2022 19:20:30 GMT, Thiago Milczarek Sayao <tsayao at openjdk.org> wrote:

>> This cleans size and positioning code, reducing special cases, code complexity and size.
>> 
>> Changes:
>> 
>> - cached extents: 28, 1, 1, 1 are old defaults - modern gnome uses different sizes. It does not assume any size because it varies - it does cache because it's unlikely to vary on the same system - but if it does occur, it will only waste a resize event.
>> - window geometry, min/max size are centralized in `update_window_constraints`;
>> - Frame extents (the window decoration size used for "total window size"):
>>     - frame extents are received in `process_property_notify`;
>>     - removed quirks in java code;
>>     - When received, call `set_bounds` again to adjust the size (to account decorations later received);
>> - Removed `activate_window` because it's the same as focusing the window. `gtk_window_present` will deiconify and focus it.
>> - `ensure_window_size` was a quirk - removed;
>> - `requested_bounds` removed - not used anymore;
>> - `window_configure` incorporated in `set_bounds` with `gtk_window_move` and `gtk_window_resize`;
>> - `process_net_wm_property` is a work-around for Unity only (added a check if Unity - but it can probably be removed at some point)
>> - `restack` split in `to_front()` and `to_back()` to conform to managed code;
>> - Set `gtk_window_set_focus_on_map` to FALSE because if TRUE the Window Manager changes the window ordering in the "focus stealing" mechanism - this makes possible to remove the quirk on `request_focus()`;
>> - Note:  `geometry_get_*` and `geometry_set_*` moved location but unchanged.
>
> Thiago Milczarek Sayao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Unity uses Compiz

I don't see any new problems on Oracle Linux 7.7. Two additional observations:

1. While doing some additional testing, I did discover a regression introduced by this patch (unrelated to your most recent commit). A stage that set to iconified before it is shown, is not iconified with your patch. This behavior happens on all distros I've tested it on. It turns out that we don't have a test that checked this case -- or rather we didn't until `SceneChangeShouldNotFocusStageTest` was added by PR #940 as part of the fix for JDK-8296621. That test now fails consistently with this patch. A simple "HelloWorld" program with `stage.setIconified(true);` called before showing the stage reproduces this bug. This needs to be fixed before this PR can be integrated. <br><br>
2. I figured out why `IconifiedTest` is so fragile on Linux. It looks like there is an intermittent (or, on some distros, not-so-intermittent) bug when showing two stages that are both always-on-top. The expectation is that if there is more than one Stage that is always-on-top, they will be stacked in the order they were created. It seems like this isn't always the case. The IconifyTest program creates a "bottom" and a "top" stages with both set to always-on-top. If I modify IconifyTest to call `getStage(false)` for the bottom stage, meaning it won't be always-on-top, the test passes for me consistently on Ubuntu 20.04.  This is unrelated to your patch, but fixing the test will make it easier to verify that there is no regression introduced by your patch.

Follow-on issues:

* related to point 1 above, I think we need new test cases to check showing stages that are initially {iconified,maximized,fullscreen}, so I'll file a follow-on test bug.
* related to point 2 above, I'll file a pair of additional follow-on bugs: a test bug to fix `IconifyTest` to make it more robust, and a product bug to track the problem of stacking order for multiple always-on-top windows.

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

PR: https://git.openjdk.org/jfx/pull/915