[Xquartz-dev] Fully self contained Xquartz.app?

[doh123]

because my main goal isn't for Xquartz itself, its for Wineskin, which has Xquartz packaged inside... because Wine has to have X11, and I try to make the apps run as much like a native app as possible, hiding Wine and Xquartz and everything from the user.  Just using the default install of X11 on the system is problematic, since I wouldn't know which features are available from what they had installed, and that Wine compiles its winex11 driver against the X11 version and location...  I've gotten past all that, right now XKB is the only thing I use thats holding me up, so I'm going to modify it to not have a hard set location, then I should be good to go.

For normal Xquartz usage, after Jeremy's reply, I see how it can be problematic, as I didn't think about full X11 usage, since I only use parts.

On Jul 14, 2010, at 4:45 AM, Eeri Kask wrote:

> Am 07/14/2010 01:08 AM, Jeremy Huddleston <jeremyhu at apple.com> schrieb:
>> On Jul 13, 2010, at 10:03, doh123 wrote:
>>> 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.
>> [....]
> 
> 
> What is wrong with the current method of installation?  What
> advantage should one expect from being able to move Xquartz.app
> around; do you ever move Xquartz.app around, for what purpose?
> 
> (Once I had to move Finder.app too, but only to avoid it from being
> started on system boot.  As opposed to X which probably can be left
> uninstalled one cannot avoid Finder (or Dock or Spotlight or etc)
> from being installed so easily.)
> 
> 
>> 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.
> 
> 
> :-)  In temptation to implement recent features please lets not
> loose from sight basic X functionality which has worked 25 years
> elsewhere from being fixed in Xquartz too --- like window borders
> painting, or more complex issues like frequent X-event dispatch
> problems which can be best observed if running something else than
> quartz-wm or no wm at all.
> 
> (Because of the latter (window entry/exit and focus events most
> troublesome) it is hard to use Xquartz for own X11-applications
> development because nobody knows where to look for problems.  In
> this context xcb can be questioned too of course.)  :-(
> 
> Greetings,
> 
>    Eeri Kask
> 
> 
> _______________________________________________
> Xquartz-dev mailing list
> Xquartz-dev at lists.macosforge.org
> http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
>