Stage Manager Problems

Jeremy Wood mickleness at gmail.com
Sat Feb 18 10:22:25 UTC 2023


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" <philip.race at oracle.com>
To "Jeremy Wood" <mickleness at gmail.com>; "Harshitha Onkar" 
<harshitha.onkar at oracle.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
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" <harshitha.onkar at oracle.com>
>>To "Jeremy Wood" <mickleness at gmail.com>
>>Cc "client-libs-dev at openjdk.org" < client-libs-dev at openjdk.org>
>>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 <client-libs-dev-retn at openjdk.org> On Behalf Of 
>>>Jeremy Wood
>>>Sent: Wednesday, February 15, 2023 10:08 PM
>>>To:client-libs-dev at openjdk.org
>>>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.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230218/58283b0c/attachment.htm>


More information about the client-libs-dev mailing list