[OpenJDK 2D-Dev] [9] RFR: JDK-8138749, , Revisited: PrinterJob.printDialog() does not support multi-mon, always displayed on primary

[Philip Race]

"in consistent"

On 1/21/16, 11:20 PM, prasanta sadhukhan wrote:
> Hi Phil,
>
> I checked with NATIVE print dialog and with other app print dialog, 
> they are positioning the dialog a little ahead of top-left corner (not 
> at 1/3rd of the window as we are doing now)
> so I did the same and positioned the dialog in consistent with our 
> NATIVE print dialog.

You mean consistently. in consistent means the opposite
Please adjust that in the code comment.

50,50 is probably OK so long as you verified this is approximately
what happens on most platforms, not just windows 8 or similar.
I don't think you will find complete consistency because apps may
control it and use different dialogs even on the same platform.
On hidpi screens this may be closer to the top-left than you intend
but I expect it is fine.

The one main thing that you should verify is what happens in the case
a native app top-level window is smaller than the print dialog and is 
positioned
at the bottom right (of the right-most display). Does the native app ensure
that the dialog is wholly on-screen ? I don't think your code will do that.
And Safari on Mac at least seems to do that. I guess that most apps try
their best to keep the dialog wholly on-screen.

-phil.


> Please find the updated webrev
> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.02/
>
> Regards
> Prasanta
> On 1/22/2016 4:59 AM, Phil Race wrote:
>> That is definitely better .. although I wonder if it would be even 
>> better
>> if you found when there is an 'active' window that you tried to
>> position the dialog such that it is near the upper-left corner of 
>> that window ?
>> Please experiment and see how that looks compared to what other apps 
>> are doing.
>>
>> -phil.
>>
>> On 01/21/2016 01:45 AM, prasanta sadhukhan wrote:
>>> Hi Phil,
>>>
>>> Please find the updated webrev
>>> http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.01/
>>> which do away with the change in ServiceUI.
>>>
>>> Regards
>>> Prasanta
>>> On 1/21/2016 2:59 AM, Phil Race wrote:
>>>> The changes in ServiceUI seem like they can cause the spec. to be 
>>>> contradicted.
>>>> It says
>>>>
>>>>    * @param gc used to select screen. null means primary or default 
>>>> screen.
>>>>
>>>> but you update the code such that it will use the active window.
>>>> If that is on a secondary screen but null was passed in.
>>>>
>>>> I am not entirely sure why ServiceUI needs to be changed at all.
>>>> It is just the caller of ServiceUI ..
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 01/20/2016 03:08 AM, prasanta sadhukhan wrote:
>>>>> Hi All,
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8138749
>>>>> webrev: http://cr.openjdk.java.net/~psadhukhan/8138749/webrev.00/
>>>>>
>>>>> Please review a fix for a long standing issue whereby it is seen that
>>>>> PrinterJob.printDialog(attr set) does not support multi-monitor 
>>>>> setup. When this API is invoked, the print dialog is always 
>>>>> displayed on the default screen device regardless of where the 
>>>>> application is running.
>>>>> This is because this method
>>>>> uses ServiceDialog class for creating the dialog and that indeed 
>>>>> supports passing a GC in which we would like to have the dialog. 
>>>>> But printer job always uses the GraphicsConfig of the default 
>>>>> screen device
>>>>> resulting in print dialog to be shown on primary device/monitor.
>>>>>
>>>>> I have not considered pageDialog() for this fix. Will create a 
>>>>> separate bugid and send a patch for that as well once this fix is 
>>>>> approved.
>>>>>
>>>>> Regards
>>>>> Prasanta
>>>>>
>>>>
>>>
>>
>