<AWT Dev> Review request for 8005997 : [macosx] Printer Dialog opens an additional title bar

Petr Pchelko petr.pchelko at oracle.com
Wed Jan 23 06:24:10 PST 2013


Sorry, my message came out of order.

Anthony wrote:
> 1. if I apply your current fix and Alt-Tab out of the print dialog, I'll get to some other app running on my desktop.
> 
> 2. When I Alt-Tab back to Java, I'll get to the open print dialog.
> 
> 3. The Java Frame cannot be activated by any means while the print dialog is displaying.
1. Yes.
2. Yes.
3. The print-dialog is natively application-modal, so I think there is no way to activate any Java Frame.

With best regards. Petr.

On Jan 23, 2013, at 6:12 PM, Anthony Petrov wrote:

> So, let me double check:
> 
> 1. if I apply your current fix and Alt-Tab out of the print dialog, I'll get to some other app running on my desktop.
> 
> 2. When I Alt-Tab back to Java, I'll get to the open print dialog.
> 
> 3. The Java Frame cannot be activated by any means while the print dialog is displaying.
> 
> Are all the above points true?
> 
> --
> best regards,
> Anthony
> 
> On 1/23/2013 18:09, Petr Pchelko wrote:
>> Hello, Anthony, Artem.
>> I have verified that the printing dialog is created via [NSPrintPanel runModalWithPageInfo:info] and page dialog is created via [NSPageLayout runModalWithPrintInfo:info]. The documentation states that both methods display the dialogs application-modally, so I suppose there is no way to bring other Java windows on top of them.
>> With best regards. Petr. On Jan 23, 2013, at 5:14 PM, Anthony Petrov wrote:
>>> Hi Petr,
>>> 
>>> The checkBlocking() should actually bring the blocker window to top. In your case the blocker is the native print dialog. I'd suggest to look at how the dialog is created in the printing code in JDK, and make sure they show the dialog modally (using the native modality support on OS X). In this case the OS will not allow one to Alt-Tab out of the print dialog to another window of the same app until the dialog is closed.
>>> 
>>> Alternatively, if using the native modality is not an option, then we have to somehow get a reference to the native NSWindow/NSPanel instance associated with the native print dialog, and bring it to top in the checkBlocking() method.
>>> 
>>> --
>>> best regards,
>>> Anthony
>>> 
>>> On 1/23/2013 11:50, Petr Pchelko wrote:
>>>> Hello, AWT Team.
>>>> Please review the fix for the issue:
>>>> http://bugs.sun.com/view_bug.do?bug_id=8005997
>>>> The fix is available at:
>>>> http://cr.openjdk.java.net/~pchelko/8005997/webrev.00/
>>>> This is a very simple fix, we just should not show the blocker if it is a PrintingDialog. The dialog will be shown by the native system.
>>>> With best regards. Petr.




More information about the awt-dev mailing list