Re: [Xquartz-dev] Fully self contained Xquartz.app?
Am 07/14/2010 01:08 AM, Jeremy Huddleston <jeremyhu@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
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@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@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Jul 14, 2010, at 09:48, doh123 wrote:
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.
You can require that your users select the X11User.pkg which means they will have /usr/X11 on their system. This is what Codeweavers does for Crossover currently.
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,
what do you mean by that? It's not like users can configure what parts of X11 they install. They either have it or they don't. You get the version that comes with the OS.
and that Wine compiles its winex11 driver against the X11 version and location...
yeah... and you're building wine, so what's the problem?
the normal Apple X11 isn't nearly as good. Just using some from /usr/X11 might work ok, I'm far from an X11 expert. As far as I know Crossover only uses libXplugin and quartz-wm from Apple's X11, everything else they have in their app. Their app is portable, because hacked versions of their app made into wrappers can move around everywhere with no issues like i have with xkb, but I'm sure I can figure out a modification to xkb to stop that. Wine hard compiles the location of X11 dylibs on the system... I want to use something much newer and better than Apple's X11, so for now I compile Wine where X11 is in a non-existant place on other peoples machines, and DYLD_FALLBACK_LIBRARY_PATH is set on run to be the current location it should look for. I've tried some modifications to use the @exectuable_path... stuff, but theres always been weird issues without having the fallback as well. Looking close at how Crossover's worked, they are calling the fallback as well, which is how I first found out it existed. Its difficult trying to make single builds all packaged up that will run on 10.4 - 10.6 correctly without anyone having to custom compile anything. On Jul 14, 2010, at 1:17 PM, Jeremy Huddleston wrote:
On Jul 14, 2010, at 09:48, doh123 wrote:
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.
You can require that your users select the X11User.pkg which means they will have /usr/X11 on their system. This is what Codeweavers does for Crossover currently.
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,
what do you mean by that? It's not like users can configure what parts of X11 they install. They either have it or they don't. You get the version that comes with the OS.
and that Wine compiles its winex11 driver against the X11 version and location...
yeah... and you're building wine, so what's the problem?
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/xquartz-dev
On Jul 14, 2010, at 1:17 PM, Jeremy Huddleston wrote:
On Jul 14, 2010, at 09:48, doh123 wrote:
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.
You can require that your users select the X11User.pkg which means they will have /usr/X11 on their system. This is what Codeweavers does for Crossover currently.
Actually, we don't make use of anything within /usr/X11. We only require X11User.pkg because Snow Leopard switched to not installing quartz-wm or libXplugin without it. (On Leopard, they were installed as part of the base system.) Regards, Ken
On Jul 15, 2010, at 11:10, Ken Thomases wrote:
On Jul 14, 2010, at 1:17 PM, Jeremy Huddleston wrote:
On Jul 14, 2010, at 09:48, doh123 wrote:
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.
You can require that your users select the X11User.pkg which means they will have /usr/X11 on their system. This is what Codeweavers does for Crossover currently.
Actually, we don't make use of anything within /usr/X11. We only require X11User.pkg because Snow Leopard switched to not installing quartz-wm or libXplugin without it. (On Leopard, they were installed as part of the base system.)
Right, my statement was ambiguous. "This" was referring to "Codewecers currently requires X11User.pkg because that is the only way to get quartz-wm on SL". I realize Codeweavers uses its own stack for everything else, but I don't suggest you do the same unless you really need that level of customization and control that they do.
On Jul 14, 2010, at 02:45, Eeri Kask wrote:
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?
You _CAN_ move XQuartz.app around with the current configuration. We use LaunchServices to locate it.
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.) :-(
I don't think I have an open bug report about these entry/exit/focus event issues...
participants (4)
-
doh123
-
Eeri Kask
-
Jeremy Huddleston
-
Ken Thomases