[Xquartz-dev] app_to_run not working in recent 1.4 server

Martin Otte otte at duke.edu
Fri Oct 2 14:45:32 PDT 2009


The problem was that I didn't update xinit along with the x server, so  
the DISPLAY variable that was being set in the LaunchAgent was wrong.  
Your most recent changes were not in the 1.1.1 xinit release that I  
was using. Now the app_to_run works again.

Two other minor points:

1) In any app that starts from a script in ~/.xinitrc.d, the DISPLAY  
is set to :0.0. All other applications have the correct DISPLAY (/tmp/ 
launch-*:0) I can verify this behaviour with the 2.4.0 release too on  
a Leopard machine. Is xinit setting a custom DISPLAY for apps that it  

2) In 1.4.2-apple49, my custom .Xmodmap is not being used at startup  
(or probably it is being overwritten after it is read by xinit). This  
was working in the previous apple47 server that I was using.


On Oct 2, 2009, at 2:03 PM, Jeremy Huddleston wrote:

> On Oct 2, 2009, at 08:53, Martin Otte wrote:
>> I compiled the latest 1.4 servers on snow leopard since they  
>> contain some fixes over the apple installed server. The server  
>> starts fine by either double-clicking it or by executing an  
>> application that uses the X server.
>> The only thing that doesn't work (in the apple48 and apple49  
>> servers) is that the app listed in the app_to_run no longer runs. I  
>> have app_to_run set as an xterm so that I have a terminal when the  
>> server starts. In bundle-main.c:
>>   if(argc == 1 || (argc == 2 && !strncmp(argv[1], "-psn_", 5))) {
>>       /* Now, try to open a display, if so, run the launcher */
>>       display = XOpenDisplay(NULL);
>>       if(display) {
>>           /* Could open the display, start the launcher */
>>           XCloseDisplay(display);
>>           return execute(command_from_prefs("app_to_run",  
>>       }
>>   }
>> The XOpenDisplay call is returning a null display,
> If that's the case, then DISPLAY is not set to a value it expects.   
> What happens when you just execute (from Terminal)?
> /Applications/Utilities/X11.app/Contents/MacOS/X11.bin
> There should be output that mentions why it's not working.
> Do you have 2.4.1_alpha1 installed on your system?  If so, that  
> would be why X11.app isn't using that path.  XQuartz.app owns  
> DISPLAY when both are installed.
>> so the app_to_run is never run. Is this the only place where the  
>> app_to_run is executed from?
> The behavior is to only execute app_to_run if you're starting  
> X11.app by double clicking and it owns the launchd socket...
>> I don't know if this works with the latest 1.5 server because I  
>> haven't upgraded the necessary X11 protos to compile the server.
> It's working here on 1.4 through master...
> I'd recommend keeping /usr/X11 the way it's shipped from Apple  
> unless you want to get possibly clobbered.  That's why we're using / 
> opt/X11 for the MacOSForge.org releases.
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

More information about the Xquartz-dev mailing list