[Xquartz-dev] Building bundle'able Xquartz

[doh123]

I don't use startx... just run the main xserver executable directly (the X11.bin file in XQuartz.app).  You only need the main xserver executable, and xkbcomp... maybe quartz-wm, but most people should already have that on their machine, and you have to start it manually (you can add code to start it in the xorg server itself after initialization is done).  Other than that, the xkb files needed in the share folder, and then just tons of dylibs in the lib folder.

trust me, the whole thing isn't easy to get working, but the symlink is really only needed for xkb initialization.  If you want to modify the xkb code to work another way, feel free, but there is no other clean way with the current code... it MUST have a hard set compiled in path for itself and where it finds the files it needs.  /tmp is the best solution, and it only needs the symlink for a few seconds.  /tmp is a temp folder for use by programs... its full read/write there to be used in ways such as this.  If you find another way to get xkb to initialize properly with a dynamic path, be sure to let me know  :-)

On Jun 23, 2011, at 7:54 PM, Tony Bernardin wrote:

> thanks for the reply doh123. I'll consider it, although I'm still holding out for someone to suggest a way it could be done "more cleanly". Still I understand changing all the install_names after the fact, but what about all the other references to paths, e.g., in startx, they'd all point the /tmp/Whatever/... Do you also change these retroactively?
> 
> On Thu, Jun 23, 2011 at 4:19 PM, doh123 <doh123 at doh123.com> wrote:
> I already do this for Wineskin... it works decently enough
> 
> You need a unique location to build XQuartz to, as some of the stuff in it (namely xkb) has to have a hard coded set path, and its not easy to edit after building, so you need to build it yourself.
> 
> I suggest building it as installed in /tmp as it works great for me since all users have full read/write to /tmp.  I build WineskinX11 (My slightly modified XQuartz build) as installed to /tmp/Wineskin.  While I fix all my libraries with install_name_tool to run relative to the executable location, for things like xkb, I have it start up by making a symlink at /tmp/Wineskin to the current x11 location inside the app at the time.  It only really needs it for xkb initialization and not later for running, so if that symlink is only important for starting up X, just rm one if there and create a new one on every run... just choose a good name in /tmp that will be unique for sure to build it to run from, not /opt since it would require a password to make a symlink there, and not in /tmp... so non-Admin users can still run the app ok with no special installation.
> 
> You can edit XQuartz itself to do certain things at startup when you do your own build to start up certain other programs in X, and then your application would in actuality just be the same as being XQuartz.app named what you want, customized to start up certain things, but with the libraries inside...  I really think this is how XQuartz should always be, but they like it in /opt  :-)
> 
> Oh I'd recommend probably editing the source to read the xmodmap from somewhere in through /tmp/whatever too, since by default it only uses ~/.Xmodmap, and you never know what some user might have that messes thing up.
> 
> -doh123
> 
> On Jun 23, 2011, at 5:47 PM, Tony Bernardin wrote:
> 
>> Hi,
>> 
>> I'm making mac os x application bundle for one of my applications and would like to embed the XQuartz release into it. The reason herefore is that the default X11 on 10.6.x has a flaw that Apple has not been fixing and I would like to follow the typical bundle way where you simply need to drag the bundle onto your Applications folder to run it. My first question is, is can this be reasonably realized? So far I've thought of two approaches:
>> 
>> 1. Get the XQuartz release, install it, then copy the /opt/X11 content to my My.app/Contents/Libraries/X11 and fix it up. I can modify all the install_names and even edit all the /opt/X11 paths that appear in scripts (e.g., startx), but I don't know what is all just hardcoded into some of the other executables.
>> 
>> 2. Get the source and build a relocatable XQuartz to embed in the app bundle. I've been trying to follow the instructions here: http://xquartz.macosforge.org/trac/wiki/1.4-apple-git-10.5.5 but when I run autogen.sh for the xorg-macros it complains that I can't use a relative path as --prefix=../Libraries/X11. I'm not sure how the prefix gets used internally, i.e., does it contribute to producing paths that get injected into some of the code at compile time or not.
>> 
>> I would greatly welcome any advice on creating an embedable X11 release, such that I could run startx from my app bundle's start-up script and have it use only resources that are contained in the app bundle.
>> 
>> Thanks,
>> 
>> 
>> -- 
>> Tony Bernardin,
>> Postdoctoral Researcher,
>> W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES)
>> University of California, Davis
>> 
>> 
>> _______________________________________________
>> Xquartz-dev mailing list
>> Xquartz-dev at lists.macosforge.org
>> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
> 
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
> 
> 
> 
> 
> -- 
> Tony Bernardin,
> Postdoctoral Researcher,
> W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES)
> University of California, Davis
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/xquartz-dev/attachments/20110623/b5552f6c/attachment.html>