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
