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