Stage Manager Problems

[Philip Race]

 >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?
>>
>>  1. frame.isActive()
>>  2. frame.isFocused()
>>  3. 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/20230216/9cf00b5e/attachment.htm>