I use Slackware for my OS and I always start X from the command line so your mileage may vary a bit here. Please bear with me as this gets a little confusing. My description will follow the chronological sequence.
When the startx command is issued the startx script executes xinit, a binary. Among other things, xinit will try to run your system’s xinitrc script(s). These can be in various locations (e.g. ~/.xinitrc or /etc/X11/xinit/xinitrc), but I believe the most common location is /etc/X11/xinit/xinitrc. That script then runs a default system startfluxbox script, which then typically runs the default user’s startup script, which in turn starts the Fluxbox binary. I have altered this sequence so that for me it goes like this:
- The xinit binary starts X using files like /etc/X11/xorg.conf and ~/.Xdefaults,
- The xinit binary then runs the xinitrc.fluxbox script,
- xinitrc.fluxbox merges my /etc/X11/xinit/.Xmodmap into the system’s generic settings,
- xinitrc.fluxbox then runs the /usr/bin/startfluxbox script,
- Which in turn executes the /usr/bin/fluxbox binary using the ~/.fluxbox/init file settings.
I am not a fan of the somewhat recursive nature of Fluxbox’s “startup” scripts. Fluxbox has designed them to cover the contingencies of a first-time user, a user with no startup script, and users with their own startup scripts. I understand the reasons for this, but since I’m on a single-user system, I just don’t need all this. And quite frankly, it confuses me. So I’ve eliminated a user-specific startup script, and I’ve whittled down the scripts in my sequence to using as little code as possible. Then as a matter of trying for standardization, I separate my X settings from my Fluxbox settings.
You do not have to have an .Xdefaults, and mine is used strictly for color settings; the rest of my X settings I take care of in xinitrc.fluxbox. My .Xmodmap is strictly X level keyboard mappings (like changing the Capslock key to Tab). I keep my Fluxbox settings in startfluxbox (namely, I set the background image here). Some people put all their Fluxbox settings with their X settings in xinitrc.fluxbox (I used to). Some people prefer to use more of Fluxbox’s built-in methodology for much of this stuff. Others put all their X settings in .Xdefaults. None are wrong; it’s a matter of preference. I try to keep it simple to help me keep it all straight.
Let’s look at some of these files. Of interest in my .Xmodmap I map the right Alt, Ctrl, and Windows (Super) keys to their equivalent left side keys. This is important for getting the same behavior out of each. Later I’ll talk about the Fluxbox Keys file, which can get some unexpected results if you don’t do something like this.
Now check out my xinitrc.fluxbox script where I do most everything X related. The early stuff should be pretty self-explanatory. I do a bunch of xset commands (which can be done in an .Xdefaults or various other locations). After that I do something different from most people. Rather than use a ~/.fluxbox/startup script to start apps, I run the /usr/bin/startfluxbox in the background and grab its process ID number, execute all the apps I want, and then hang there waiting until Fluxbox finishes. This is an old method that has the advantage of allowing me to execute commands after Fluxbox starts but not from within it. In other words, these apps are started from X, not Fluxbox. X won’t allow you to start applications without a running window manager, so you can’t just execute them prior to starting Fluxbox. There are various advantages and reasons for doing this, but for me its mostly about to which files I log. It also lessens the number of files I deal with.
Next we have my system startfluxbox script called from xinitrc.fluxbox. I set my background here because I want to get the image up as quickly as possible so I don’t see any default color flash for a moment. Most people just use the method Trent mentioned with the rootCommand option in the Fluxbox Init file, and it works fine. I’m just trying to squeak a couple microseconds out of it. I’ve played extensively with this, and there are several other things you can do (like using X to set the background as commented out in my xinitrc.fluxbox – very dangerous), but ultimately I decided that this is the best method for me. It’s a little faster, and again it lessens the number of files I use for configuration.
Notice that I’ve cropped quite a bit out of this script and out of the whole normal Fluxbox startup sequence as this is the only startup script to be called. At this point the Fluxbox binary launches, which brings us to the Fluxbox config files….