FWIW: I wrapped this exploration up by submitting two bug reports:
9074851, 9074856 .
Regards,
- Jeremy
------ Original Message ------
From "Jeremy Wood" <[email protected]>
To "Philip Race" <[email protected]>; "Harshitha Onkar"
<[email protected]>
Cc "[email protected]" <[email protected]>
Date 2/18/2023 5:22:25 AM
Subject Re[2]: Stage Manager Problems
I made a 5 min video here:
https://drive.google.com/file/d/1al0huWBGhdSeqXrNU_if8HpQGOrxFMFH/view?usp=sharing
(I’ll delete this link in a month or two.)
It shows the original complaint, but also around t=3 min it starts to
show a worse problem:
If you have Stage Manager active and you iconify a JFrame, the JFrame
never returns to a Frame.NORMAL state. (At least not in this simple
test.) This leads to major repaint problems.
So… my immediate question is: now what?
Should I take what I have and just submit an openJDK ticket? (Or a
separate ticket for each problem?) Is it OK to write a ticket with an
undefined expected behavior, or is that something we should try to
clarify here first?
Regards,
- Jeremy
------ Original Message ------
From "Philip Race" <[email protected]>
To "Jeremy Wood" <[email protected]>; "Harshitha Onkar"
<[email protected]>
Cc "[email protected]" <[email protected]>
Date 2/16/2023 1:31:23 PM
Subject Re: Stage Manager Problems
>The more I look at this: I’m afraid the crux of this problem is Stage
Manager has introduced a new window state that Java’s AWT architecture
can’t really describe yet. (But I’d love to be proved wrong…?)
I think you are right. I do not have Ventura to see / test for myself
but everything I am hearing
sounds like with Stage Manager active the "minimise" button just
causes a different compositing transform
to be applied to the window and adds that gesture blocking overlay to
make it so that it can't see mouse events
or presumably receive focus for keyboard events, and the app is
*intentionally* (as in Apple's intention)
ignorant of anything having changed in its state.
So it is anyone's guess what we can do about this and even if we
should do something what would it be ..
Maybe there's some clue in the latest SDK - ie a new API ?
FWIW One of our team members said he tried this mode for 5 mins but
multiple (non-java) apps were
so broken in this mode he turned it off again.
-phil.
On 2/16/23 2:04 AM, Jeremy Wood wrote:
Harshitha,
Thanks for the suggestions. I think those don’t really resolve the
problem, though.
In the original sample program (having only 1 frame) watching the
keyboard focus could help identify when there’s a change, but if
there’s a second frame: that second window could retain the focus and
the first window still can’t answer the question, “Are you minimized
now?”
(I have an updated sample program
<https://drive.google.com/file/d/1uzUUDnAlPoHlFdbVgunwpFKvn4Ies-6-/view?usp=sharing>
here with two frames if anyone’s interested.)
Further: the window could lose the focus at any time (if a system
dialog came up), so I don’t think focus should act as a proxy for
visibility.
I did find tonight a work-around for our app a few hours ago. We have
some native code that identifies all visible windows, their bounds
and their title. If I consult that list: I see a window that matches
our (sufficiently unique) window title. And its bounds do not at all
match with what Java says our window’s bounds are. And it is
positioned so 99% of it overlaps with a window called “Gesture
Blocking Overlay”. (All Stage Manager thumbnails appear to have an
overlay window with this title.) So it’s a very kludgy and brittle
work around, for for the time being it works.
This leads me to believe the Mac OS windowing system doesn’t consider
the frame to be “hidden”. I think the window remains technically
visible. And Mac OS knows it has new bounds. But the peer in Java is
oblivious to the new bounds/state. (I examined the peer LWWindowPeer
in a debugger: it still thinks the window is visible (technically
true) and its bounds are unchanged (not true).)
The more I look at this: I’m afraid the crux of this problem is Stage
Manager has introduced a new window state that Java’s AWT
architecture can’t really describe yet. (But I’d love to be proved
wrong…?)
- Jeremy
------ Original Message ------
From "Harshitha Onkar" <[email protected]>
To "Jeremy Wood" <[email protected]>
Cc "[email protected]" < [email protected]>
Date 2/16/2023 1:57:56 AM
Subject RE: Stage Manager Problems
Hi Jeremy,
Does any of the following options help in your case to determine
whether or not the frame is iconified?
frame.isActive()
frame.isFocused()
frame.isAlwaysOnTop()
Thanks & Regards,
Harshitha Onkar
From: client-libs-dev <[email protected]> On Behalf
Of Jeremy Wood
Sent: Wednesday, February 15, 2023 10:08 PM
To:[email protected]
Subject: Stage Manager Problems
We’re experiencing problems related JFrames while Stage Manager
<https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html>
is active Mac.
When Stage Manager is active the yellow minimize button on our
JFrame’s appears to “minimize” our app. But as far as our Frame is
concerned:
1. Frame.getExtendedState() does not indicate we’re in an ICONIFIED
state
2. Frame.isShowing() returns true
3. a java.awt.desktop.AppForegroundListener believes our app is in
the foreground.
We want to identify when we’re in this hidden state. Is there any
other property we can consult to help identify this state?
I’m happy to submit an openjdk ticket if needed, but first I wanted
to sanity check that I’m not missing something. (I also tried
querying
<https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22>
the openJDK bug database, but didn’t see any hits.)
I tried rummaging around in Mac-specific classes (like
CPlatformWindow), but I didn’t see any promising leads. It’s always
possible I missed something, though.
Attached is a small 200-line demo app.
