<AWT Dev> RFR: 8256465: [macos11] Java frame and dialog presented full screen freeze application
prr at openjdk.java.net
Fri May 7 19:58:39 UTC 2021
On Tue, 27 Apr 2021 07:08:58 GMT, Tejpal Rebari <trebari at openjdk.org> wrote:
>> It is something of a new paradigm \(yes its been there since 10\.12\,
>> that\'s not what I mean\) so
>> we should make sure its supportable\.
>> The system dialog UI talks of \"documents\" which might tell us something
>> about the mindset
>> of the folks who designed it\. I also find it surprising it is a global
>> system setting\.
>> It seems like something that is better set per\-application\. Of course if
>> a Java runtime is used
>> for multiple applications that wouldn\'t help but it is moot for now so
>> let\'s not spend time on that
>> It would be interesting to have an enumeration of known and suspected
>> problems with this\.
>> \- where is it inappropriate UI \- if we have an unowned dialog it is
>> really weird to popup it up in a new tab\.
>> \?\? Are just at odds with the mac desktop where dialogs are always owned
>> windows \?
>> \?\?\? Do they imagine that all windows can layout nicely even if they
>> don\'t get the size they want \?
>> \?\?\? I\'m having trouble picturing how all this works smoothly
>> \- where do we have behavioural problems \- full screen oddities\,
>> application freezes\, incorrect behaviour
>> of menu bars \.\. focus \.\.
>> \- what scenarios do we need to examine\? \?
>> I can imagine it would take some time to properly go through all of
>> these and I think we should
>> schedule that rather than just disabling this and in all likelihood
>> forgetting about this\.
>> Do we have a go\-with\-the disabling RFE to support it \?
>> If applications are freezing then disabling it might be an appropriate
>> short term solution
>> We could consider a system property to prevent the disabling \.\. in case
>> some one has an app where they\'d
>> really like to use it and understand the risks\.
>> Maybe new API is needed to make it supportable \- which would suggest to
>> me that Apple made a mistake
>> in the way they implemented this\.
>> Probably this disabling is needed for older releases as new API won\'t
>> make it back to those\.
>> On 4\/10\/21 1\:30 PM\, Sergey Bylokhov wrote\:
>> It would be interesting to have an enumeration of known and suspected problems with this.
>> * where is it inappropriate UI - if we have an unowned dialog it is really weird to popup it up in a new tab.
>> Are just at odds with the mac desktop where dialogs are always owned windows ?
> Mac OS Alert opens up in new window no matter what the Prefer Tab setting is.
>> Do they imagine that all windows can layout nicely even if they don't get the size they want ?
>> I'm having trouble picturing how all this works smoothly
>> * where do we have behavioural problems - full screen oddities, application freezes, incorrect behaviour
>> of menu bars .. focus ..
>> * what scenarios do we need to examine ?
>> I can imagine it would take some time to properly go through all of these and I think we should
>> schedule that rather than just disabling this and in all likelihood forgetting about this.
>> Do we have a go-with-the disabling RFE to support it ?
> I have filed a RFE for this : https://bugs.openjdk.java.net/browse/JDK-8266026.
@trebari where are we with my (off-line) suggestion to you that this fix be updated such that a System Property "-Djdk.allowTabbedWindows=true" be defined that lets someone over-ride the disabling so that folks can at least try out the effect of this on their apps whilst we figure out a supportable API ?
More information about the awt-dev