Stage Manager Problems

[Jeremy Wood]

FWIW: I wrapped this exploration up by submitting two bug reports: 
9074851, 9074856 .

Regards,
  - Jeremy

------ Original Message ------
>From "Jeremy Wood" <mickleness at gmail.com>
To "Philip Race" <philip.race at oracle.com>; "Harshitha Onkar" 
<harshitha.onkar at oracle.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
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" <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/20230227/49563d0c/attachment.htm>