June 2011 - Xquartz-dev - lists.macosforge.org

2.6.0_beta2
by Jeremy Huddleston 29 Sep '11

29 Sep '11

I just uploaded 2.6.0_beta2 which pulls in all the updates in X11R7.6 RC1 plus the xorg-server 1.9.3 RC1 server. You can obtain the update by checking for updates in the X11 menu or directly here: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.6.0_beta2.dmg The full ChangeLog is available here: http://xquartz.macosforge.org/trac/wiki/ChangeLog The only XQuartz specific changes I want to address before making rc1 are related to RandR. If you find any regressions or serious issues, please let me know. --Jeremy

3 11

Re: [Xquartz-dev] How to suppress .xinitrc warning dialog?
by Dave Ray 28 Jun '11

28 Jun '11

The problem is solved. I learned there is a requirement that filenames of scripts in ~/.xinitrc.d must end in ".sh". I had put Bourne shell scripts there, but did not give them .sh suffixes. As soon as I renamed the scripts, they worked. That wasn't intuitive for me, as I spend a lot of time on Linux systems which don't require the .sh suffix on rc scripts. My bad. I figured it out by looking in here: /opt/X11/lib/X11/xinit/xinitrc.d/98-user.sh: if [ -d "${HOME}/.xinitrc.d" ] ; then for f in "${HOME}"/.xinitrc.d/*.sh ; do [ -x "$f" ] && . "$f" done unset f fi Dave

2 1

Re: [Xquartz-dev] How to suppress .xinitrc warning dialog?
by Dave Ray 27 Jun '11

27 Jun '11

On Sun Jun 26 15:41:09 PDT 2011, Jeremy Huddleston wrote: >>> mkdir ~/.xinitrc.d >>> echo "USERWM=/usr/X11/bin/twm" > ~/.xinitrc.d/00-twm.sh >>> chmod 755 ~/.xinitrc.d/00-twm.sh That works on my system. > You can also exec it if you'd rather do that... > > mkdir ~/.xinitrc.d > echo "exec /usr/X11/bin/twm" > ~/.xinitrc.d/99-twm.sh > chmod 755 ~/.xinitrc.d/99-twm.sh That is not working on my system! XQuartz 2.6.3_rc1 MacOSX 10.6.8 quartz-wm starts up when launching XQuartz with the following: $ pwd /Users/davidray/.xinitrc.d $ ls -al total 8 drwxr-xr-x 3 davidray staff 102 Jun 26 22:22 . drwxr-xr-x+ 69 davidray staff 2346 Jun 26 22:20 .. -rwxr-xr-x 1 davidray staff 64 Jun 26 22:19 99-twm $ cat 99-twm exec /opt/X11/bin/twm $ ls -al ~/.x* /Users/davidray/.xinitrc.d: total 8 drwxr-xr-x 3 davidray staff 102 Jun 26 22:22 . drwxr-xr-x+ 69 davidray staff 2346 Jun 26 22:20 .. -rwxr-xr-x 1 davidray staff 64 Jun 26 22:19 99-twm $ Same results whether I click XQuartz in dock, invoke an X11 app, or run "startx" in the terminal. Bug? -Dave

2 1

Re: [Xquartz-dev] How to suppress .xinitrc warning dialog?
by Dave Ray 27 Jun '11

27 Jun '11

On Jun 26, 2011, at 17:21, Dave Ray wrote: > >> On Sun Jun 26 15:41:09 PDT 2011, Jeremy Huddleston wrote: >mkdir ~/.xinitrc.d >echo "USERWM=/usr/X11/bin/twm" > ~/.xinitrc.d/00-twm.sh >chmod 755 ~/.xinitrc.d/00-twm.sh Thanks, that makes it clear. When I tried it before, I was trying to exec the wm in the script (like in .xinitrc), which wasn't working. Instead I should be setting USERWM in the script. Correct? I guess my follow-up question is: If I need to invoke another process before the wm starts, how is that done? In the "wrong" .xinitrc method, that pre-process just comes on a line before the wm command. I could do: USERWM="/usr/bin/somethingelse && /usr/X11/bin/twm". Is there a better way?

2 1

Re: [Xquartz-dev] How to suppress .xinitrc warning dialog?
by Dave Ray 27 Jun '11

27 Jun '11

On Sun Jun 26 15:41:09 PDT 2011, Jeremy Huddleston wrote: >>> >>>> I am creating a pkg installer which includes a custom ~/.xinitrc file on the target machine. >>> >>> Don't do that! Use ~/.xinitrc.d scripts >> >> Ok, fine, I can do that... > >> Just so I can improve my understanding, if I take the ~/.xinitrc and just rename it and put it in ~/.xinitrc.d, what's the difference? Why is that better? > > Search the archives for plenty of discussion on this. Having ~/.xinitrc means you override *everything* in the global xinitrc rather than just starting a different WM. Okay, I understand why ~/.xinitrc.d is better. I just tried this. It appears that when using ~/.xinitrc.d/, XQuartz starts up whatever window manager is set my USERWM (or quartz-wm if not set) BEFORE running anythig in that directory. So the idea of having the wm command executed from a file in ~/.xinitrc.d/ does not work; it must be set in USERWM. So if I am trying to set the wm from an installer, the installer has to modify ~/.profile to set USERWM, or something like that. I understand the advantage of not nuking the user prefs in ~/.xinitrc.d/, but the method setting of the ENV from an installer becomes a lot less clean than by setting it in .xinitrc. Hmm. >> If I am trying to create an installer that automates the setup for a different window manager, there's no way for the installer to know which previous startup script has to be disabled in ~/.xinitrc.d. > > Please explain what you mean by installer. What are you trying to do? If you want to install another WM from a .pkg, just install it. Let the user choose their WM themselves. A .pkg installer that installs a window manager (without Fink or Macports) and preconfigures everything so that it will run when XQuartz lanched. > An installer should not do that. I would just install the WM and let the user do what they want. If they want your new WM, they can set USERWM themselves. If you want to set USERWM for them, then give that as an optional choice in the installer. It will definitely be an optional choice in the installer. I want to give the user the option of having the installer preconfigure it for them, if desired, and trying to figure out the best way to do that. Dave

2 1

Re: [Xquartz-dev] How to suppress .xinitrc warning dialog?
by Dave Ray 26 Jun '11

26 Jun '11

On Sat Jun 25 11:28:06 PDT 2011, Jeremy Huddleston wrote: >On Jun 25, 2011, at 11:09, Dave Ray wrote: > >> I am creating a pkg installer which includes a custom ~/.xinitrc file on the target machine. > >Don't do that! Use ~/.xinitrc.d scripts Ok, fine, I can do that. Will the dialog go away of I do that? FYI, I am using this startup script to set the window manager to be something other than quartz-wm. Just so I can improve my understanding, if I take the ~/.xinitrc and just rename it and put it in ~/.xinitrc.d, what's the difference? Why is that better? The directory ~/.xinitrc.d doesn't exist by default. Is there any reason to expect that something else will need to go there? My concern is that if I create a script in ~/.xinitrc.d that invokes window manager A, and then sometime in the future another script is placed there that is invoked window manager B, then we have a problem: two window managers will try to be invoked. If I am trying to create an installer that automates the setup for a different window manager, there's no way for the installer to know which previous startup script has to be disabled in ~/.xinitrc.d. If ~/.xinitrc.d is used, changing window managers would require editing the files by hand. Using ~/.xinitrc seems like a better solution to prevent that condition and allow an automated install. Do you have a suggestion for how the installer can manage the automated window manager change in ~/.xinitrc.d without creating this potential condition?

2 1

How to suppress .xinitrc warning dialog?
by Dave Ray 25 Jun '11

25 Jun '11

I am creating a pkg installer which includes a custom ~/.xinitrc file on the target machine. On the first run of XQuartz (or if the plist is deleted) XQuartz throws a warning dialog asking if the .xinitrc file should be moved aside. Is there a way I can suppress this warning dialog? Is there a 'defaults write' command I can execute in the installer to take care of this? Thanks, Dave

2 1

Building bundle'able Xquartz
by Tony Bernardin 24 Jun '11

24 Jun '11

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

3 7

Re: [Xquartz-dev] Building bundle'able Xquartz
by Tony Bernardin 24 Jun '11

24 Jun '11

In response to Jeremy's comments: About the color banding issue for the Apple provided X11 (__not__ XQuartz) here is an older message that contains example code. I haven't personally double-checked it recently (mostly because I don't have handy access to the original Apple X11 distribution), but my colleague confirmed the issue still happened with the latest 10.6.x. At the time of writing the first message, a friend of mine at Apple confirmed the symptoms with 10.6.4 and said he'd file a bug agains GLX. ---------- Forwarded message ---------- From: Tony Bernardin <tbernardin(a)ucdavis.edu> Date: Mon, Sep 6, 2010 at 12:59 PM Subject: Issue with using GLX on mac os >= 10.6.3 so I got 'round to coding up a little example to check out why the Vrui apps looked like crap on the newer mac os X. Attached you will find the glx source code and the reference cocoa code. You see in the image that something is up with the color representation in the glx code. When I query the geometry in glx the returned bit depth is 24. Oliver do you have access to a 10.5 box to see if the glx example produces something decent there? cheers, -- Tony Bernardin, PhD Candidate, Computer Science, University of California, Davis -- Tony Bernardin, Postdoctoral Researcher, W.M. Keck Center for Active Visualization in the Earth Sciences (KeckCAVES) University of California, Davis

2 1

XQuartz 2.6.3_rc2
by Jeremy Huddleston 21 Jun '11

21 Jun '11

Hi everyone, I just uploaded 2.6.3_rc2 to the servers. You can get it by checking for updates or downloading it directly here: http://static.macosforge.org/xquartz/downloads/SL/XQuartz-2.6.3_rc2.dmg The only change from rc1 is the newer version of xorg-server. This release pulls in xorg-server-1.10.3 RC1 to address some GLX bugs that were present in 2.6.3_rc1. 2.6.3 is a very conservative release. There are a slew of changes already committed and planned for 2.7.0, so I wanted to get out one more release of 2.6.x to finish polishing it off. If you notice any issues (especially regressions from earlier releases), please let me know. I plan to release 2.6.3 in about 3 weeks (once xorg-server 1.10.3 is released). Thanks, Jeremy

2 2