Due to persuasive arguments by certain people on this list ;) I think I solved this the right way. Take a look at this: http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
Well, it's a step in the right direction... to bad it doesn't actually work =/ It x11-exec gets executed which causes X11.app to get executed, which causes Xquartz to get executed. My xterm shows up, but I don't have a dock icon or menu bar... --Jeremy On Dec 13, 2007, at 15:59, Ben Byer wrote:
Due to persuasive arguments by certain people on this list ;) I think I solved this the right way. Take a look at this:
http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Kevin's seeing it, too (and I'm busy compiling). Are you getting a dock icon? If not, this sounds like the fundamental problem that I encountered way back in the day where the dock icon would disappear due to some wacky race condition. Does the problem go away if you change the launchd plist to directly execute the hardcoded path instead of using x11-exec? On Dec 13, 2007, at 5:30 PM, Jeremy Huddleston wrote:
Well, it's a step in the right direction... to bad it doesn't actually work =/
It x11-exec gets executed which causes X11.app to get executed, which causes Xquartz to get executed. My xterm shows up, but I don't have a dock icon or menu bar...
--Jeremy
On Dec 13, 2007, at 15:59, Ben Byer wrote:
Due to persuasive arguments by certain people on this list ;) I think I solved this the right way. Take a look at this:
http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... http://cgit.freedesktop.org/xorg/xserver/commit/?h=xorg-server-1.2-apple&id=... -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Dec 13, 2007, at 18:47, Ben Byer wrote:
Kevin's seeing it, too (and I'm busy compiling). Are you getting a dock icon? If not, this sounds like the fundamental problem that I encountered way back in the day where the dock icon would disappear due to some wacky race condition.
No dock icon. No, I don't think it's the race condition...
Does the problem go away if you change the launchd plist to directly execute the hardcoded path instead of using x11-exec?
Yes (after reboot as well, that is)... I can look into it a bit more this weekend as well.
On Dec 13, 2007, at 7:22 PM, Jeremy Huddleston wrote:
On Dec 13, 2007, at 18:47, Ben Byer wrote:
Kevin's seeing it, too (and I'm busy compiling). Are you getting a dock icon? If not, this sounds like the fundamental problem that I encountered way back in the day where the dock icon would disappear due to some wacky race condition.
No dock icon.
Ben and I determined that by x11-exec not setting argv[0] to the full path of the executable, X11.app was not able to locate its main bundle and therefore the menubar and icon were missing. - Kevin
On Dec 13, 2007, at 7:59 PM, Kevin Van Vechten wrote:
On Dec 13, 2007, at 7:22 PM, Jeremy Huddleston wrote:
On Dec 13, 2007, at 18:47, Ben Byer wrote:
Kevin's seeing it, too (and I'm busy compiling). Are you getting a dock icon? If not, this sounds like the fundamental problem that I encountered way back in the day where the dock icon would disappear due to some wacky race condition.
No dock icon.
Ben and I determined that by x11-exec not setting argv[0] to the full path of the executable, X11.app was not able to locate its main bundle and therefore the menubar and icon were missing.
Also, for the record, this is the same reason why X11.app (the bundle launcher) has to rename Xquartz to X11 when it runs -- so that it keeps the same icon. -- Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
Also, for the record, this is the same reason why X11.app (the bundle launcher) has to rename Xquartz to X11 when it runs -- so that it keeps the same icon.
Yeah, I realized that... I just don't understand the mechanics of why that is the case... since my example in the previous email shows... well... it working when argv[0] is not the full path...
And actually, you're solution still has the second dock icon issue. Place /A/U/X11.app in the dock and execute it. A new dock icon is created.
On Dec 13, 2007, at 23:56, Jeremy Huddleston wrote:
And actually, you're solution still has the second dock icon issue. Place /A/U/X11.app in the dock and execute it. A new dock icon is created.
However, it works as expected if I make a "simple" x11-exec as follows: (15:32:18 Fri Dec 14 2007 jeremy@yuffie Power Macintosh) /usr/X11/libexec $ cat x11-exec exec /Applications/Utilities/X11.app/Contents/MacOS/X11 "${@}" --- So we should be able to do this... there's just some weirdness involved that I'm a bit confused about...
This duplicate icon was actually an error on my end. org.x.X11 was mapping to /usr/X11/bak/X11.app on my system. Anyways, I started moving this "stuff" over to xinit. Right now, it is mostly working. launchd's startup envokes startx to start the server and dock behavior is as expected. xinit does not yet have the necessary code to check defaults for things like noauth tcp. Additionally, using X11.app to start the server (via X11.app -query <ip> or by disabling launchd support) falls back on the current server_main() in server_main.c. We need to move over this extra support from server_main.c into xinit.c within __APPLE__ #ifdefs, then just tighten up server_main() to exec startx. --Jeremy here's how to compile/install xinit: git-clone git://anongit.freedesktop.org/git/xorg/app/xinit cd xinit export CFLAGS="-Wall -O2 -arch i386 -arch ppc -pipe" ./autogen.sh --prefix=/usr/X11 --mandir=/usr/X11/man --with- launchagents-dir=/System/Library/LaunchAgents make make install On Dec 14, 2007, at 15:34, Jeremy Huddleston wrote:
On Dec 13, 2007, at 23:56, Jeremy Huddleston wrote:
And actually, you're solution still has the second dock icon issue. Place /A/U/X11.app in the dock and execute it. A new dock icon is created.
However, it works as expected if I make a "simple" x11-exec as follows:
(15:32:18 Fri Dec 14 2007 jeremy@yuffie Power Macintosh) /usr/X11/libexec $ cat x11-exec exec /Applications/Utilities/X11.app/Contents/MacOS/X11 "${@}"
---
So we should be able to do this... there's just some weirdness involved that I'm a bit confused about..._______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Really? It needs argv to be the full path? That doesn't make sense since this works: PATH=/Applications/TextEdit.app/Contents/MacOS TextEdit --Jeremy On Dec 13, 2007, at 19:59, Kevin Van Vechten wrote:
Ben and I determined that by x11-exec not setting argv[0] to the full path of the executable, X11.app was not able to locate its main bundle and therefore the menubar and icon were missing.
On Dec 13, 2007, at 10:13 PM, Jeremy Huddleston wrote:
Really? It needs argv to be the full path? That doesn't make sense since this works:
PATH=/Applications/TextEdit.app/Contents/MacOS TextEdit
In that case I think it's able to infer the bundle from the directory containing TextEdit, but consider the following: $ ln -s /Applications/TextEdit.app/Contents/MacOS/TextEdit /tmp/foo $ /tmp/foo 2007-12-13 22:21:33.780 foo[2185:10b] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting - Kevin
Jeremy Huddleston wrote:
Really? It needs argv to be the full path? That doesn't make sense since this works:
PATH=/Applications/TextEdit.app/Contents/MacOS TextEdit
Most of get bundle path etc are based around _NSExecutableGetPath, which, if you look at http://www.opensource.apple.com/darwinsource/10.5/dyld-95.3/src/dyldAPIs.cpp there is a comment: * Note that _NSGetExecutablePath will return "a path" to the executable not a * "real path" to the executable. That is the path may be a symbolic link and * not the real file. Basically it usually works, but can get confused. It is less likely to become confused if passed a full path to the real executable in argv[0]. Peter -- Peter O'Gorman http://pogma.com
The main reason why I'm asking all this is because I want o figure out how to divorce most of the bundle from the X11.app bundle and place it somewhere in /usr/X11. That is, the stuff used by Xquartz (main.nib, the localization, etc) shouldn't really be in that .app. We have this weird interdependence between the two, and I think the end goal should be like this: launchd runs /usr/X11/bin/startx which is an sh script in xinit. This checks org.x.X11 plist to figure out extra command line arguments (the stuff the 'server start X11.app' did) and starts Xquartz. Xquartz then loads its UI stuff, sets the icon, etc. That way, people running Xquartz directly will see it with menus and the right icon. Also, I think this is a bit stronger from a software engineering standpoint. The only problem with that is that we'll then have a new two-icon icon issue when people put /A/U/X11.app in the dock... hrm... On Dec 13, 2007, at 22:46, Peter O'Gorman wrote:
Jeremy Huddleston wrote:
Really? It needs argv to be the full path? That doesn't make sense since this works:
PATH=/Applications/TextEdit.app/Contents/MacOS TextEdit
Most of get bundle path etc are based around _NSExecutableGetPath, which, if you look at http://www.opensource.apple.com/darwinsource/10.5/dyld-95.3/src/dyldAPIs.cpp there is a comment:
* Note that _NSGetExecutablePath will return "a path" to the executable not a * "real path" to the executable. That is the path may be a symbolic link and * not the real file.
Basically it usually works, but can get confused. It is less likely to become confused if passed a full path to the real executable in argv[0].
Peter -- Peter O'Gorman http://pogma.com _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Thu, Dec 13, 2007 at 11:43:33PM -0800, Jeremy Huddleston wrote:
That way, people running Xquartz directly will see it with menus and the right icon. Also, I think this is a bit stronger from a software engineering standpoint. The only problem with that is that we'll then have a new two-icon icon issue when people put /A/U/X11.app in the dock... hrm...
So can we accept that but make them different? i.e. have one icon for the Xserver, and one that sort of represents the X applications? but I'm not sure what one would want to do wrt to menus if / when switching between the two.
Well the one that "represents the X applications" *is* the X server. With the way things are in git, it's behaving like it was before 2.1.1. putting the app in the dock and clicking it launches a new xterm and a new icon represents the server. I'm actually fine with that, but I don't know how others will react. As it is, though, I believe disabling launchd support will still cause the 10.4 behavior. I know vmware does some weird hackery with .apps that cause it to "just work" as expected. I think we should just try putting as much of x11-exec and server_main() functionality into xinit and actually use that to start Xquartz (which loads its resources rather than grabbing them from X11.app with some weird argv[0] and fork()ing hacks). What are peoples' thoughts? --Jeremy On Dec 14, 2007, at 04:45, Derek Fawcus wrote:
On Thu, Dec 13, 2007 at 11:43:33PM -0800, Jeremy Huddleston wrote:
That way, people running Xquartz directly will see it with menus and the right icon. Also, I think this is a bit stronger from a software engineering standpoint. The only problem with that is that we'll then have a new two-icon icon issue when people put /A/U/X11.app in the dock... hrm...
So can we accept that but make them different?
i.e. have one icon for the Xserver, and one that sort of represents the X applications? but I'm not sure what one would want to do wrt to menus if / when switching between the two. _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
AFAIK, one of the big limiting factors here is that Xquartz has to either live inside a .app bundle, or pretend to do so with exec/argv/ etc, in order to have a dock icon at all. On Dec 14, 2007, at 12:04 PM, Jeremy Huddleston wrote:
Well the one that "represents the X applications" *is* the X server. With the way things are in git, it's behaving like it was before 2.1.1. putting the app in the dock and clicking it launches a new xterm and a new icon represents the server. I'm actually fine with that, but I don't know how others will react.
As it is, though, I believe disabling launchd support will still cause the 10.4 behavior.
I know vmware does some weird hackery with .apps that cause it to "just work" as expected. I think we should just try putting as much of x11-exec and server_main() functionality into xinit and actually use that to start Xquartz (which loads its resources rather than grabbing them from X11.app with some weird argv[0] and fork()ing hacks).
What are peoples' thoughts?
--Jeremy
On Dec 14, 2007, at 04:45, Derek Fawcus wrote:
On Thu, Dec 13, 2007 at 11:43:33PM -0800, Jeremy Huddleston wrote:
That way, people running Xquartz directly will see it with menus and the right icon. Also, I think this is a bit stronger from a software engineering standpoint. The only problem with that is that we'll then have a new two-icon icon issue when people put /A/U/X11.app in the dock... hrm...
So can we accept that but make them different?
i.e. have one icon for the Xserver, and one that sort of represents the X applications? but I'm not sure what one would want to do wrt to menus if / when switching between the two. _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
No, that's not the case. The dock icon isn't a result of pretending to be a .app. If you execute Xquartz directly right now, it has an icon. I think I know of a way to tackle this and start integrating with xinit. I'm a bit busy this weekend but do have a few hours today and will finish during the week. Have you had a chance to look at the 1.4 event code? I'd like to get that usable, so we can start putting out drop-in binaries using the 1.4 server code base to get feedback. I've been keeping it and master up to date with all changes in the 1.2 branch (exept master doesn't yet have your null-pointer checking band-aid in fb). On Dec 15, 2007, at 02:36, Ben Byer wrote:
AFAIK, one of the big limiting factors here is that Xquartz has to either live inside a .app bundle, or pretend to do so with exec/argv/ etc, in order to have a dock icon at all.
On Dec 14, 2007, at 12:04 PM, Jeremy Huddleston wrote:
Well the one that "represents the X applications" *is* the X server. With the way things are in git, it's behaving like it was before 2.1.1. putting the app in the dock and clicking it launches a new xterm and a new icon represents the server. I'm actually fine with that, but I don't know how others will react.
As it is, though, I believe disabling launchd support will still cause the 10.4 behavior.
I know vmware does some weird hackery with .apps that cause it to "just work" as expected. I think we should just try putting as much of x11-exec and server_main() functionality into xinit and actually use that to start Xquartz (which loads its resources rather than grabbing them from X11.app with some weird argv[0] and fork()ing hacks).
What are peoples' thoughts?
--Jeremy
On Dec 14, 2007, at 04:45, Derek Fawcus wrote:
On Thu, Dec 13, 2007 at 11:43:33PM -0800, Jeremy Huddleston wrote:
That way, people running Xquartz directly will see it with menus and the right icon. Also, I think this is a bit stronger from a software engineering standpoint. The only problem with that is that we'll then have a new two-icon icon issue when people put /A/U/X11.app in the dock... hrm...
So can we accept that but make them different?
i.e. have one icon for the Xserver, and one that sort of represents the X applications? but I'm not sure what one would want to do wrt to menus if / when switching between the two. _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
On Dec 15, 2007, at 8:49 AM, Jeremy Huddleston wrote:
No, that's not the case. The dock icon isn't a result of pretending to be a .app. If you execute Xquartz directly right now, it has an icon.
I think I know of a way to tackle this and start integrating with xinit. I'm a bit busy this weekend but do have a few hours today and will finish during the week.
Have you had a chance to look at the 1.4 event code? I'd like to get that usable, so we can start putting out drop-in binaries using the 1.4 server code base to get feedback. I've been keeping it and master up to date with all changes in the 1.2 branch (exept master doesn't yet have your null-pointer checking band-aid in fb).
Yes, I know you've been keeping the two in sync -- thanks. Hopefully you won't have to do that anymore -- switching to 1.4 is my #1 priority for this upcoming week. After a bit of fiddling, I got xorg-server-1.4-apple to build and run. I've only tested it a little bit -- I ran quartz-wm, xterm and xev -- and the events code seemed to be working correctly, except that caps-lock needs to be hit 4 times to enable and then disable. (I know how to fix that one.) I seem to recall you said that 'Shift' is broken? - Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
On Fri, Dec 14, 2007 at 12:04:44PM -0800, Jeremy Huddleston wrote:
Well the one that "represents the X applications" *is* the X server.
I realise that. I was asking 'does it help if we were to change that?' 1) Have something else represent the X applications 2) Have a seperate program (maybe w/o an icon?) for the Xserver Then we have two ways in which things get started: 1) Automatic (no manual start of Xquartz, so no icon for it per-se) 2) Manual (so an actual Dock icon for the server, and the existing one for the 'Apps') The only reason I suggest this is that i've a vague memory of the server code playing games to fake out the Dock's view of which program is in the forground when an actual X appliation is running. Output by the Xserver when it's in the background would not be an issue, the only difficulty is getting k/b input. One could simply have the 'X app program' feed such to the server say XTEST, or via some other back door channel. DF
Hi Derek, I think there are two things here, really... the short-term fix, and the long-term fix. Right now, I think it's best to try to get a fix that solves the problem as easily as we can without being too much of an ugly hack. For the long term, some people have suggested separate icons for each X window. That is completely impractical at the server level, but if we start putting that onto quartz-wm's shoulders it is theoretically possible. I look at things like vmware fusion that create .app bundles on the fly for windows applications, and I see that it is possible... I'm just not very close to understanding how. Additionally, the server needs a dock icon for now, since it is the only way a user has to bring it to the foreground. On Dec 15, 2007, at 07:59, Derek Fawcus wrote:
On Fri, Dec 14, 2007 at 12:04:44PM -0800, Jeremy Huddleston wrote:
Well the one that "represents the X applications" *is* the X server.
I realise that. I was asking 'does it help if we were to change that?' 1) Have something else represent the X applications 2) Have a seperate program (maybe w/o an icon?) for the Xserver
Then we have two ways in which things get started: 1) Automatic (no manual start of Xquartz, so no icon for it per-se) 2) Manual (so an actual Dock icon for the server, and the existing one for the 'Apps')
The only reason I suggest this is that i've a vague memory of the server code playing games to fake out the Dock's view of which program is in the forground when an actual X appliation is running.
Output by the Xserver when it's in the background would not be an issue, the only difficulty is getting k/b input. One could simply have the 'X app program' feed such to the server say XTEST, or via some other back door channel.
DF _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
What he said. (I'd love to have individual Dock icons for each X application, but this is simultaneously difficult to achieve, and difficult to do in a way that is generically correct for all X applications. Therefore, let's not worry about it until we get the trivial 1-icon case working.) On Dec 15, 2007, at 8:55 AM, Jeremy Huddleston wrote:
Hi Derek,
I think there are two things here, really... the short-term fix, and the long-term fix. Right now, I think it's best to try to get a fix that solves the problem as easily as we can without being too much of an ugly hack.
For the long term, some people have suggested separate icons for each X window. That is completely impractical at the server level, but if we start putting that onto quartz-wm's shoulders it is theoretically possible. I look at things like vmware fusion that create .app bundles on the fly for windows applications, and I see that it is possible... I'm just not very close to understanding how.
Additionally, the server needs a dock icon for now, since it is the only way a user has to bring it to the foreground.
On Dec 15, 2007, at 07:59, Derek Fawcus wrote:
On Fri, Dec 14, 2007 at 12:04:44PM -0800, Jeremy Huddleston wrote:
Well the one that "represents the X applications" *is* the X server.
I realise that. I was asking 'does it help if we were to change that?' 1) Have something else represent the X applications 2) Have a seperate program (maybe w/o an icon?) for the Xserver
Then we have two ways in which things get started: 1) Automatic (no manual start of Xquartz, so no icon for it per-se) 2) Manual (so an actual Dock icon for the server, and the existing one for the 'Apps')
The only reason I suggest this is that i've a vague memory of the server code playing games to fake out the Dock's view of which program is in the forground when an actual X appliation is running.
Output by the Xserver when it's in the background would not be an issue, the only difficulty is getting k/b input. One could simply have the 'X app program' feed such to the server say XTEST, or via some other back door channel.
DF _______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
_______________________________________________ Xquartz-dev mailing list Xquartz-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/xquartz-dev
Ben Byer CoreOS / BSD Technology Group, XDarwin maintainer
participants (5)
-
Ben Byer
-
Derek Fawcus
-
Jeremy Huddleston
-
Kevin Van Vechten
-
Peter O'Gorman