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

[Jeremy Huddleston]

On Oct 2, 2009, at 14:45, Martin Otte wrote:

> Hi,
>
> 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.

But it should fall back on using ":0" if it doesn't get "org.x.X11:0"

http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.4-apple&id=245baef28386c35c6da30096517ea084d5d822b9

I bet I'm unsetting DISPLAY in bundle_main.c if it doesn't match the  
BundleIdentifier ... I might need to add a case to accept just "/:0"  
as well... or just push out a new xinit release and depend on that...

> 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 launches?

Yeah... that's by design.  That's the easiest way to guarantee it will  
work for all startup paths of X11.  There might be another option, but  
there's nothing inherently broken with this behavior.  You're just  
following a different path into the server.

> 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.

Yeah... that's an old bug that is just now more prevalent.  A bit  
about that...

With the xkb config files in place (xkeyboard-config), our keymap gets  
trashed by XKB.  We've skirted this issue by simply not including  
these files in our releases and deleting them when they are present  
(they snuck in during a 2.4.0 alpha I think).  1.7 now requires XKB...  
meaning that if they're not present, the server fails to start.  The  
easiest solution was to put them in place, let XKB do its thing, then  
trash its mappings.

As a side note, XKB is ugly, messy, and getting rewritten... hopefully  
things will be better in 1.8...

We can probably execute xmodmap after updating the keymap to pull in  
custom updates.  This has always been a bug, but nobody ever bothered  
to complain about it.  If you had "Follow System Keymap" enabled and  
switched keymaps, your customizations would be nuked.

Please open tickets about this one, so I don't forget.

--Jeremy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3333 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20091002/74eff859/attachment.bin>