initialization when running xmonad using xnest
I'm not ready to switch to using xmonad 100% of the time yet, so for the time being I'm running it using xnest. The problem I'm having is that I don't know how to get xmonad (or xnest) to read an initialization file (e.g. a .xinitrc file) in these circumstances. Does anyone have any suggestions? Thanks in advance, Mike
On Thu, Aug 02, 2007 at 11:34:42PM -0700, Michael Vanier wrote:
I'm not ready to switch to using xmonad 100% of the time yet, so for the time being I'm running it using xnest. The problem I'm having is that I don't know how to get xmonad (or xnest) to read an initialization file (e.g. a .xinitrc file) in these circumstances. Does anyone have any suggestions?
Neither your window manager nor your X server is supposed to *ever* touch .xinitrc; this is the responsibility of your display manager, or if you do not use one, the server driver program. For instance, untested: startx -- /usr/bin/Xnest :1 will load your .xinitrc file in the context of an Xnest on display 1. Stefan
Huh, I think I was asking the wrong question then. I don't really want to do all the things that are done in my .xinitrc file. I noticed, though, that (for instance) my .Xresources are ignored inside the xnested xmonad, so I have to do xrdb ~/.Xresources again to get them to work right (presumably because xnest is running X on display 1, not 0). Similarly, I have to do "xsetroot -solid black" again to get a black background. So I put these commands in my startup script like this: #!/bin/sh Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1 xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources /usr/local/bin/xmonad& XMONAD_PROC=$! wait $XMONAD_PROC kill $XNEST_PROC but the xrdb and xsetroot commands did nothing. However, if I did it like this: #!/bin/sh Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1 /usr/local/bin/xmonad& XMONAD_PROC=$! xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources wait $XMONAD_PROC kill $XNEST_PROC it works fine. I don't know why this is -- does xmonad have to be running in order for the xsetroot and xrdb commands to take effect? Why should that be? Mike Stefan O'Rear wrote:
On Thu, Aug 02, 2007 at 11:34:42PM -0700, Michael Vanier wrote:
I'm not ready to switch to using xmonad 100% of the time yet, so for the time being I'm running it using xnest. The problem I'm having is that I don't know how to get xmonad (or xnest) to read an initialization file (e.g. a .xinitrc file) in these circumstances. Does anyone have any suggestions?
Neither your window manager nor your X server is supposed to *ever* touch .xinitrc; this is the responsibility of your display manager, or if you do not use one, the server driver program. For instance, untested:
startx -- /usr/bin/Xnest :1
will load your .xinitrc file in the context of an Xnest on display 1.
Stefan
On Fri, Aug 03, 2007 at 02:09:00PM -0700, Michael Vanier wrote:
Huh, I think I was asking the wrong question then. I don't really want to do all the things that are done in my .xinitrc file. I noticed, though, that (for instance) my .Xresources are ignored inside the xnested xmonad, so I have to do
xrdb ~/.Xresources
again to get them to work right (presumably because xnest is running X on display 1, not 0). Similarly, I have to do "xsetroot -solid black" again to get a black background. So I put these commands in my startup script like this:
#!/bin/sh
Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1
xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources
/usr/local/bin/xmonad& XMONAD_PROC=$!
wait $XMONAD_PROC kill $XNEST_PROC
but the xrdb and xsetroot commands did nothing. However, if I did it like this:
#!/bin/sh
Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1
/usr/local/bin/xmonad& XMONAD_PROC=$!
xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources
wait $XMONAD_PROC kill $XNEST_PROC
it works fine. I don't know why this is -- does xmonad have to be running in order for the xsetroot and xrdb commands to take effect? Why should that be?
X11 Protocol Specification, chapter 10, paragraph 3: A server goes through a cycle of having no connections and having some connections. At every transition to the state of having no connections as a result of a connection closing with a Destroy close-down mode, the server resets its state as if it had just been started. This starts by destroying all lingering resources from clients that have terminated in RetainPermanent or RetainTempo- rary mode. It additionally includes deleting all but the predefined atom identifiers, deleting all properties on all root windows, resetting all device maps and attributes (key click, bell volume, acceleration), resetting the access control list, restoring the standard root tiles and cursors, restor- ing the default font path, and restoring the input focus to state PointerRoot. So after xsetroot exits, the server resets. After xrdb exits, the server resets. xmonad starts with a clean setup. This (mis)feature is not an issue if you use xinit/startx because xinit itself counts as a connected client. Stefan
Wow! Stefan, you never cease to amaze me. Mike Stefan O'Rear wrote:
On Fri, Aug 03, 2007 at 02:09:00PM -0700, Michael Vanier wrote:
Huh, I think I was asking the wrong question then. I don't really want to do all the things that are done in my .xinitrc file. I noticed, though, that (for instance) my .Xresources are ignored inside the xnested xmonad, so I have to do
xrdb ~/.Xresources
again to get them to work right (presumably because xnest is running X on display 1, not 0). Similarly, I have to do "xsetroot -solid black" again to get a black background. So I put these commands in my startup script like this:
#!/bin/sh
Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1
xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources
/usr/local/bin/xmonad& XMONAD_PROC=$!
wait $XMONAD_PROC kill $XNEST_PROC
but the xrdb and xsetroot commands did nothing. However, if I did it like this:
#!/bin/sh
Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 2> /dev/null & XNEST_PROC=$! DISPLAY=:1
/usr/local/bin/xmonad& XMONAD_PROC=$!
xsetroot -display :1 -solid black xrdb -display :1 $HOME/.Xresources
wait $XMONAD_PROC kill $XNEST_PROC
it works fine. I don't know why this is -- does xmonad have to be running in order for the xsetroot and xrdb commands to take effect? Why should that be?
X11 Protocol Specification, chapter 10, paragraph 3:
A server goes through a cycle of having no connections and having some connections. At every transition to the state of having no connections as a result of a connection closing with a Destroy close-down mode, the server resets its state as if it had just been started. This starts by destroying all lingering resources from clients that have terminated in RetainPermanent or RetainTempo- rary mode. It additionally includes deleting all but the predefined atom identifiers, deleting all properties on all root windows, resetting all device maps and attributes (key click, bell volume, acceleration), resetting the access control list, restoring the standard root tiles and cursors, restor- ing the default font path, and restoring the input focus to state PointerRoot.
So after xsetroot exits, the server resets. After xrdb exits, the server resets. xmonad starts with a clean setup.
This (mis)feature is not an issue if you use xinit/startx because xinit itself counts as a connected client.
Stefan
On Aug 3, 2007, at 17:09 , Michael Vanier wrote:
Huh, I think I was asking the wrong question then. I don't really want to do all the things that are done in my .xinitrc file. I noticed, though, that (for instance) my .Xresources are ignored inside the xnested xmonad, so I have to do
Correct thing to do is have a ~/.xinitrc.Xnest and do: startx ~/.xinitrc.Xnest -- Xnest :1 (the full pathname to .xinitrc is important, otherwise it runs your regular .xinitrc and passes the stuff before the -- as arguments. on the other hand, you could use that to customize your .xinitrc...) Hm, except that XFree86 broke startx at one point such that it always passed them as arguments. I *think* xorg fixed that, but you should test to make sure startx does the right thing in that case. Or possibly use xinit directly instead of startx. (startx is just a wrapper around xinit that invokes a standard system-wide xinitrc and/ or xserverrc as needed. Since you're specifying both the xinitrc and an X server, you can safely use xinit directly.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
That works, or more specifically, it works if I do: sudo startx ~/.xinitrc.Xnest -- /usr/bin/Xnest :1 -name "xmonad" +kb -ac -geometry 1152x768 Thanks for all the help, guys! Mike Brandon S. Allbery KF8NH wrote:
On Aug 3, 2007, at 17:09 , Michael Vanier wrote:
Huh, I think I was asking the wrong question then. I don't really want to do all the things that are done in my .xinitrc file. I noticed, though, that (for instance) my .Xresources are ignored inside the xnested xmonad, so I have to do
Correct thing to do is have a ~/.xinitrc.Xnest and do:
startx ~/.xinitrc.Xnest -- Xnest :1
(the full pathname to .xinitrc is important, otherwise it runs your regular .xinitrc and passes the stuff before the -- as arguments. on the other hand, you could use that to customize your .xinitrc...)
Hm, except that XFree86 broke startx at one point such that it always passed them as arguments. I *think* xorg fixed that, but you should test to make sure startx does the right thing in that case. Or possibly use xinit directly instead of startx. (startx is just a wrapper around xinit that invokes a standard system-wide xinitrc and/or xserverrc as needed. Since you're specifying both the xinitrc and an X server, you can safely use xinit directly.)
--brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH
participants (3)
-
Brandon S. Allbery KF8NH -
Michael Vanier -
Stefan O'Rear