RFR: 8296972: [macos13] java/awt/Frame/MaximizedToIconified/MaximizedToIconified.java: getExtendedState() != 6 as expected. [v2]
Dmitry Markov
dmarkov at openjdk.org
Wed Jun 14 20:52:04 UTC 2023
On Wed, 14 Jun 2023 20:09:45 GMT, Phil Race <prr at openjdk.org> wrote:
> I don't like the idea of a delay in either of the ways discussed here. And although I do think that its much better to wait for delivery of an event, I'm not sure I understand the windowState listener proposal. How do you know in this code that the transition of iconified-> normal will then followed by normal->maximised ? Perhaps you'll wait for ever ? But I don't know what the macOS native model is for all of this. This sequence is kind of odd and I'm curious what happens on older macOS releases - Sergey touched on this but I don't see direct followup. There seems to be assumptions it was like this previously but now it is slower ?
>
> I suggest explicit verification of what happens on macOS 12.6. Are we now getting two native events when there used to be only one ?
We cannot move a frame directly from `ICONIFIED` to `MAXIMIZED_BOTH` and vice versa. We need to go through the `NORMAL` state, (i.e. `ICONIFIED` -> `NORMAL` -> `MAXIMIZED_BOTH`). If my memory does not fail me we use that approach from the very beginning.
We perform two state-transitions subsequently and don't care of real state of the frame between them. It used to work till macOS 13 where the transition from one state to another takes a bit longer.
In other words we do `ICONIFIED` -> `NORMAL` and then immediately `NORMAL` -> `MAXIMIZED_BOTH` but the frame is NOT in `NORMAL` state yet.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/14226#issuecomment-1591957725
More information about the client-libs-dev
mailing list