I'm actually for this kind of application. Separate X servers would mean a more Mac feel to each application. OTOH, it probably uses more system resources so I guess it shouldn't be overused either. Since X11 is still an optional install you have to make really sure that you're linking to your local libraries and not those in /usr/X11/. Personally I prefer static linking in these cases since your app is the only one that's going to load the libraries anyway, but YMMV. One trick I've seen used in another application (can't remember which) is to define the hard coded path to a variable name and then in the initialization code set that variable to _NSGetExecutablePath() + some suffix ("../Resources/xkb" perhaps). This might or might not work depending on how it's used. I guess it's a starting point though. That function is in /usr/include/dyld/mach-o/dyld.h. HTH, -- Pelle Johansson 13 jul 2010 kl. 23.40 skrev doh123:
Thanks for the info
Thats some things I didn't think about... how I use it in Wineskin, I don't need a full Xquartz so I leave out all the extra apps and such. Mine is movable, inside the App that also has Wine and the game and such, but because of xkb, I have to compile it all to a set location, then use symlinks on run into the .app. This is nice, but I end up building it to a hidden folder in /Applications so it makes it so the .app doesn't work unless it can create that symlink... which needs a admin account, so its kind of annoying... I know xkb has the compiled time path, which is my main problem. I'll have to figure out how to modify at least xkb to pull the path from an environment variable.. would probably be the easiest.
I'll take a look at kXquartzSetRootless, maybe I can add in a way to do this... but it might be a waste of time if RANDR will be working soon, since it just use it in my current work around I do to fake resolution changing and things in Wineskin... changing global OSX resolution compared to what Wine is calling... and running Wine in a virtual desktop with quartz-wm not running... drawing that on Xquartz fullscreen fakes it into looking like normal fullscreen gaming.
I'd love to help testing/modifying RANDR in any way I can. I've used the patches that was on the list earlier from Jan, but they didn't seem to compile by default... I made some minor changes to actually get it to compile, but (probably due to my changes) its far from working anything remotely like Codeweavers did with theirs.
-doh123
On Jul 13, 2010, at 2:35 PM, Jeremy Huddleston wrote:
On Jul 13, 2010, at 10:03, doh123 wrote:
I'm having issues making some modifications to Xquartz, I was wondering if I might get some pointers to... one of which I think could benefit as a change to how Xquartz.app works... I'm not that up on Xquartz source code and not an extremely experienced programmer, its just kind of a hobby thing.
I've been working on a way to make a fully self contained Xquartz.app and not have a /opt or whatever install location. This is actually easy to do with the current code as long as I want the Xquartz.app to always be in the same exact place... but when I want it to be movable, and the .app to be launchable from any location on the system, it runs into problems. I'm pretty sure the only problem I have left is the fact that xkb wants a hard coded location (dylibs are easy to move around and find)... so any tips or ideas what I can do in the source to make that location movable would be greatly appreciated. I think this would actually be beneficial to Xquartz, making it more like a real Mac app.
The problem lies in the fact that "X11" is more than just the server. Users expect a set of command line utilities to be present. Sure, you could place those somewhere like XQuartz.app/Contents/bin and have that path added to $PATH ... as part of this, you'd also want to put the libraries in XQuartz.app/Contents/lib and do some magic setting the ids of the libs to be @executable_path/../lib/libXWhatever.1.dylib (note that this way it resolves correctly for MacOS/X11.bin and bin/xwininfo)
The real problems lie in xkb utilities, xrdb, xinit, etc which all have compile-time paths set. You'll need to modify all those utilities to get hints from the environment (or their own path) to figure out where their data is.
All in all, this is really more trouble than it is worth, IMO...
As it is right now, you can move around XQuartz.app just fine. Also, many other .apps have extra data outside their .app bundle.
I'd also like to know how to switch Xquartz from fullscreen to rootless and back.. without having to click the preference checkmark option, use key combinations or restart the server. A way I could tell it from the command line or whatever so that it can be a scripted change... if thats not currently possible, where should I look in the code to change that around? This is at least until RANDR works...
That's not currently possible. Look at the kXquartzSetRootless handler in darwinEvents.c
These changes are to fix issues I have with how I use Xquartz built into Wineskin (http://wineskin.doh123.com/), but I really think making a fully self contained app would benefit Xquartz.
I haven't heard back from Jan about the RandR changes, so I think I'll just start with her patches and try to get something usable in 2.6.0. If you're interested in getting RandR working and testing it with wineskin, that would help out.
--Jeremy
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev