I recently reported a bug with XAqua 0.6 about not starting from the commandline - which turned out to be a mistake on my part about not updating the symlink. My question is: wouldn't it be easier to have all the files in the
/usr/X11R6/bin directory and symlink the other way? Then users can move the application they see (which is just a symlink) to anywhere they want, just as they're used to, without breaking anything. Or is there a specific reason why this is a bad idea?
Good question. We used to put XDarwin.app in /usr/X11R6/bin, but it was moved for a number of reasons:
1. Symlinks don't show up with their proper application icon in the Finder, only aliases do. (This might change in the future.) We need to be able to install the entire XFree86 release from the command line and making aliases is difficult at best from the command line.
2. Having the main application installed in /Applications seems to follow the Mac OS X way of doing things. Not everything is installed in /usr/X11R6 anyway. There are also things in /etc/X11 which will cause problems if moved. People who want to move XDarwin and start from the command line, will know how to change the symlink pointing to it. In this case, I think the confusion was more because we did it differently in the previous test release, than because a user would expect /Applications/XDarwin.app to be a symlink.
3. As a side effect, this is more flexible. You can have as many XDarwin.app versions as you want scattered around. All of them will start correctly whereever they are. The one you want to start from the command line can be easily changed by moving a symlink. Previously we had a preferred place where the "one true" XDarwin.app lived in /usr/X11R6/bin.
4. The /usr/X11R6/bin directory becomes much nicer to look at in the Finder. Previously if you went there to make a new alias you would find that there were two XDarwin "things" in the directory.
This breaks point #3, and I'm not even sure it works, but what about making XDarwin in XDarwin.app/Contents/MacOS/ a symlink?
That what it'd look correct in the Finder and it is more consistent with other ports of XFree86.
This wouldn't help the original posters problem. The resources needed by XDarwin.app are still sitting in /Applications/XDarwin.app. Starting from the command line you would still need to have a pointer to the bundle where all these resources are.
Note that the current way of doing things is consistent with other ports if you are launching from the console. The IOKit version of the X server is in /usr/X11R6/bin as you'd expect. Its only for compatibility with the Mac OS X GUI that we add some Mac OS X specific extensions. We did this by directly extending the standard way of doing things where /usr/X11R6/bin/X is a symlink to the actual X server, except now we also have a symlink to the Mac OS X compatible X server (/usr/X11R6/bin/XDarwinQuartz).
> This breaks point #3, and I'm not even sure it
> works, but what about making XDarwin in
> XDarwin.app/Contents/MacOS/ a symlink?
I realized that you might have been suggesting something different from what I first thought. I suppose you could place a complete application bundle in /usr/X11R6/bin/XDarwin.app and then put a "stub" bundle in /Applications/XDarwin.app which mainly consists of symlinks back to the proper place in the complete bundle. You might need to have things like the Info.plist and icons as a actual file, but the executable and most other resources I think would have to work as symlinks. I would still suggest that this "Christmas tree" of symlinks is a lot of complication just to avoid putting things outside of /usr/X11R6/.
I should note that there is an install time setting honored by XFree86 which will cause nothing to be installed outside of /usr/X11R6. If you put the line:
#define NothingOutsideProjectRoot YES
in xc/config/cf/host.def and then build and install, you will end up with what you want. Ie. nothing will be placed outside of /usr/X11R6 and everything should work. In particular, XDarwin.app will be put back in /usr/X11R6/bin. Of course, this will also stop anything from being installed in /etc/X11 and these things will instead be merged under /usr/X11R6/.
As of MacOS 10.0.4, symlinks show up with their correct icons, at least on my machine. At least new symlinks get their correct icons,old ones seem to look the same as always.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.