Re: X11 article, for review
Re: X11 article, for review
- Subject: Re: X11 article, for review
- From: Jim Elliott <email@hidden>
- Date: Sun, 30 Mar 2003 12:15:17 -0600
This looks like another helpful article! Thanks for giving us a chance
to offer suggestions on how to make it even better. I've scanned what
other list members have offered up so far and don't think I'm being
redundant. If someone else has already mentioned any of these ideas,
perhaps in a private reply, I apologize for the repetition.
I also loved being reminded about the "shebang" pronunciation. I love
that pun, and I'd not seen it for years.
The first potential issue I noticed was in the discussion, towards the
bottom of page 2, about what's happening on the .xinitrc line that
fires up quartz-wm. You say "The window manager hasn't been put in the
background, so it will run in place of the current shell session."
There are actually two things going on on this line, and I think this
treatment confuses them (and possibly the reader) somewhat. If there is
another list member who can correct my understanding, please weigh
in--I don't claim to be the ultimate authority on X initialization
processing, but here's my understanding of the situation:
It's the "exec" keyword that causes quartz-wm to replace the shell, not
the lack of an ampersand, and this is nothing more than a small
efficiency optimization, because it saves the overhead of keeping a
now-useless shell process running for the duration of the X session.
The fact that the window manager (or at least some process) is not
backgrounded is a separate issue, and has to do with the fact that the
X server interprets the termination of the xinitrc script as a signal
that the user is done using X, and will itself exit at that point. So
if all commands were backgrounded, the script would "run off the end"
and X would terminate right after starting up.
Does that make sense? Can you think of a worthwhile way to clarify it
in the article?
My other questions are less weighty. I'm still a little nervous about
your proposal to have your .login set the value of DISPLAY if it's not
set. At least now it won't clobber other existing values that might
have been set up by sshd or the like, which is a good improvement. The
problem I have is that several programs (like the X-aware version of
Emacs) have two interfaces, both X based and text oriented, and decide
which to use based on the presence or absence of the DISPLAY
environment variable. Its existence is a promise that an X server is
running. If your .login unconditionally sets this variable, and you are
ever using a terminal session without having started an X server,
trying to use one of these programs will crash instead of giving you
the expected text interface, because it has been misled by the
existence of a DISPLAY variable that really shouldn't be set.
The proposal from the mailing list to use an "open" command to fire up
an instance of Terminal within the .xinitrc sounds safer to me,
because that Terminal window will have a legitimate value of DISPLAY,
set up by the X server itself. Of course, then you have the confusion
of trying to keep track of which Terminal windows are running under X,
and which aren't. Does anyone know if there's a way to supply
command-line arguments to Terminal that give it a distinctive
appearance, so the X-aware windows could be told apart from the others?
That sort of visual distinctinveness is one of the advantages of using
xterm as the X-world terminal, versus Terminal for the Mac OS world.
But I understand your desire to stick with the familiarity and features
of Terminal. I don't necessarily have a good answer for this one.
Perhaps just a written caveat about the potential pitfalls in your
proposed approach, and a note that some users may instead want to
manually set the value of DISPLAY in Terminal windows they want to use
with X?
Finally, if you care to get into how X forwarding works a bit more, you
might want to note that your "cfcl" alias really needs to be used only
once, and that once you've got the forwarded X session going, you'd use
commands like "xterm &" on cfcl to open new windows. Otherwise you're
creating multiple tunnels, which use multiple proxy X servers on cfcl.
This will work, but isn't necessarily resource-efficient.
Anyway, the volume of my response shouldn't be interpreted as deep
problems with the article. I think it's great, and I'm just trying to
see if there's a way I can help make it a little better.
Thanks,
-Jim
On Saturday, Mar 29, 2003, at 23:03 America/Chicago, Rich Morin wrote:
I have finished the first draft of an article on "X11 Tweaks"
for "Section 7", my column in MacTech Magazine. Please look
it over (http://www.cfcl.com/rdm/section7/2003.05.X11.1.pdf)
and let me know of any errors, omissions, etc.
-r
--
email: email@hidden; phone: +1 650-873-7841
http://www.cfcl.com/rdm - my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback:
http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.
_______________________________________________
x11-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/x11-users
X11 for Mac OS X FAQ: http://developer.apple.com/qa/qa2001/qa1232.html
Report issues, request features, feedback: http://developer.apple.com/bugreporter
Do not post admin requests to the list. They will be ignored.