hg: macosx-port/macosx-port/jdk: Fix for MACOSX_PORT-765: Unable to run an GUI app remotely.

[Alexander Zuev]

On 12/4/11 20:37, Mike Swingler wrote:
> On Dec 4, 2011, at 12:13 AM, alexander.zuev at oracle.com wrote:
>
>> Changeset: c50bdc544e22
>> Author:    kizune
>> Date:      2011-12-04 12:13 +0300
>> URL:       http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c50bdc544e22
>>
>> Fix for MACOSX_PORT-765: Unable to run an GUI app remotely.
>> Do not issue error on awt.dylib loading if we detect that process is initiated by remote or daemon process.
>>
>> ! src/macosx/native/sun/awt/awt.m
> I don't get it. Why didn't you just remove the +[AWTStarter isConnectedToWindowServer] check if you are going to allow all possible launch modes? Why do the extra work of asking for the session all over again? Is there some failure modes you are still filtering against?
Yep, it was - in 10.6. If session was uninitialized it meant that there 
is no user logged in into the system so we filtered out the system-wide 
daemons such as cron or inetd for being able to start Java application 
without implicitly specifying that it is headless. I thought it is safer 
to do. Seems that this flag was removed from Lion headers so i assume 
that additional logic is not required here so i'm about to remove my new 
function from awt.m and will just disable the isConnectedToWindowServer 
check (without actually removing the function in case we will change our 
minds later).
>
> FYI, if you allow the Cocoa AWT to load when run from an SSH or daemon initiated session you _will_ get failures later when trying to use the Cocoa API when you are not logged in as console user. Perhaps this check needs to be re-thought to force headless if the session checks tell us we are not logged in as a console user?
Well - it's exactly how it is done with the XToolkit - it initializes 
and application is able to work in non-headless mode even with X server 
not accessible at place specified in DISPLAY variable until it actually 
tries to create native peer. And if it does attempts native peer 
creation without working X server only then application crashes with 
clear and understandable error message. I haven't checked what the error 
message will look like in case of Cocoa application but i don't think 
that automatic switching to the headless mode is what we need - it may 
just confuse user. If you think differently - we might reconsider it at 
any time.

With best regards,
Alexander Zuev.