Fluxbox In-Depth: Mad Customization And Other Tips

Fluxbox Configuration Files

There are really five major config files that you’ll be directly editing for Fluxbox, and one you won’t. They are:

• The Init file which with the exception of the rootCommand option, will probably never be edited by hand, and which holds all the settings for Fluxbox as a whole.
• The Apps file which defines the “States” and “Decorations” of each application (and in most cases, each application’s sub windows) such as dimension, location, its workspace (desktop), etc.
• The Startup file which, as mentioned above, is used to specify the apps you wish to launch at startup.
• The Menu file which sets up the Root Menu tree and all the apps contained therein.
• The Keys file which defines your keyboard shortcuts.

The defaults for these files are located in /usr/share/fluxbox, and personalized ones are located in ~/.fluxbox/. I personally make symlinks pointing from /usr/share/fluxbox/ to /etc/skel/ and from there to my home directory files. This prevents any accidental erasures, and keeps the default files I want to propagate (my home ones) to any potential new user accounts located in the standardized /etc/skel/ directory.

Init

First, let’s start with the file you won’t be editing by hand (or mostly won’t), the Init file. This is the file that contains all the settings for Fluxbox which you can set through the “Fluxbox Menu” part of the Root Menu. This is stuff like the Fluxbox Style you are using, the Toolbar settings (autohide, location, right or left justified), the number of workspaces, Slit behavior and placement, window behavior and placement, tab behavior, etc, etc, etc. The easy customization of all this is one of the greatest advantages of Fluxbox. There’s little to misunderstand here, and trial and error will help with what few things you may not guess by their names. When you make changes via that menu, the settings are saved into the Init file and so there is little need to edit by hand.

As touched upon above, you can execute a command with rootCommand within the Init file, and this is often used to set the background image for your desktop. At some point in your tweaking, you may try to execute more than one command within Fluxbox right when it begins, say like setting the background and opening an aterm, but rootCommand doesn’t like what you’re trying to do. The way to get around this is to write a small bash script with all the commands you want to issue, and then run that script from rootCommand. This might be obvious to some, not so much so to others. I tried a lot of things before figuring out the single command limitation, so I thought I’d mention it.

Apps

Left to its own devices, Fluxbox will edit the Apps file on its own, and you may never mess with it. The Apps file stores the settings you make for each app and each of its sub-windows (e.g., dialogue boxes). One can’t really talk about this file without talking about “States” (and “Decorations”). Window states are properties of how a window should act (and look) within Fluxbox. Maximized is a state, as is Iconified or minimized (i.e., reduced to an icon on the Iconbar part of the Toolbar). Sticky is a state meaning the application will cross from one workspace to another rather than just be limited to its assigned workspace (which is the opposite, and default, state) or whichever workspace it was started in. Transparency is available as a state for those who love their desktop image or are looking for that, “Wow!” reaction from their friends. If you right click on an application’s Titlebar or Icon, you’ll be given a list of states to change for that session. And to set a default behavior for a certain app, you simply check the states you want to apply in the “Remember” submenu. But note that there are other states that you can set that are not listed in the menu, which can be set in the Apps file.

A great example of states is my XChat app. If you recall, I have it on a second monitor to the right of my primary monitor, I have it there all the time as I basically devote that monitor to it. This means I have it set to “[Head] {2}” the second monitor, and “[Sticky] {yes}” so it will stay visible for all workspaces; and because its always visible, I don’t particularly need its Icon on the Iconbar along with other apps, so I have set it “[IconHidden] {yes}” which is not a standard option. For positioning Xchat I set “[Position] (UPPERRIGHT) {0 0}” meaning from the top right corner of my desktop, right justify XChat’s window from pixel x=0,y=0.

With XChat I have it stickied, but with Firefox I always keep those windows on workspace number two, or simply “[Workspace] {2}”. Of course, when I do want to move a Firefox window to another workspace, I simply make it sticky and switch workspaces (which can be done with no more than a click or keyboard shortcut). The Apps file is default behavior, not a hard rule.

Do you start to see the power and control you get over your system with Fluxbox? No more opening the same apps over and over again, and no more maximizing them and rearranging other windows. Once your Apps file is set up for all your programs, you’re golden. And it really doesn’t take any longer than the first time you open the app, set the window where you want it, right click on the Titlebar, and check off what states you want to remember in the menu. That’s it. There are a few like IconHidden that you have to set by editing the Apps file, but the vast majority of setup is GUI driven (if that’s what you want) and automated.

Startup

The Startup file is used to specify which apps should begin at startup. You can do other things in it, but this is the primary purpose for which it’s used. As mentioned above, I cut the user version of this file out of the startup sequence for simplicity’s sake since I’m on a single-user system. Most people will use it as intended.

Menu

I’m not going to talk much about the Menu file. It’s pretty self-explanatory and Trent already covered it well. You can add any app on your system to it, or remove any that were automatically added during the initial menu generation. And you can generate again by hand with the Fluxbox command “fluxbox-generate_menu”. There are several command line options you can give like -k makes a KDE menu, -is does a wider search for apps, -w sets homepage for console browsers, -m sets the Root Menu title (e.g., fluxbox-generate_menu -k -is -w http://www.google.com/webhp -m `hostname`). If you want to start with a more complete list of apps on your system and then slim it down, you might want to play around with this command. Use -h to see more options.

Keys

OMGILUVKEZNBBQ! Seriously, I cannot tell you how much I love this feature of Fluxbox. For those gamers or even occasional gamers amongst you, if you’ve ever played a first person shooter or flight simulator, you realize immediately that there are way too many commands to learn right off the bat, so you learn a few keys, go practice until you’ve got them memorized, then come back to learn more. Hell, practically any game these days will actually walk you through learning the basics, then you start playing, and the game itself will teach you additional commands as you go. That is precisely what you have to do with your Fluxbox keys file, and once you do, you’ll never go back to any other window manager.

I mean, the other parts of Fluxbox are wonderful. Fluxbox is so fast and light. The Apps file is an unbelievably huge time saver. But the real juice is in the Keys. Sure, you can get many of the same effects with X, and there are daemons you can run that do the same thing, but the X methods are complex and a real pain, and the daemons are just that: yet another program forever running on your system eating away at your resources. With Fluxbox, this is just part of its basic behavior, and like the simplicity of other Fluxbox settings, the Keys file is pretty damn easy.

But I’ve gotten ahead of myself, first the explanation: The Keys file is a config file that maps keys (and mouse/joystick/whatever events) to certain actions on your computer. For example, Ctrl+Alt+Delete, the good old “three finger salute” that everyone knows and loves is typically mapped to a system reboot; Alt+Tab is usually for window switching. On a more basic level, the Tab key is mapped to the Tab action, the Q is mapped to print q, the 1 to print 1, etc. But all these can be changed (remapped) if one were so inclined.

With the Keys file, you can map pretty much any keystroke or strokes to any action or actions. That’s not to say that you should go remapping the a to the f and so forth, but you would not believe how much time you can save when you don’t have to take your hand away from the keyboard. For example, using Alt+Tab to repeatedly switch back and forth between two apps as compared to grabbing the mouse, moving it to the Toolbar, selecting the other app, then selecting the point in the text where you want to paste, etc. This is clearly a simplistic example. Those reading this article have likely long since started avoiding the mouse, if not become devoted vi fanatics. But to drive home the point to those who still love the mouse, let me ask you this: Have you ever had to help your mom/uncle/friend with their computer, and having told them to switch to the other program, then had to watch and wait while they muddled through using the mouse to do something that you know is nothing more than a flick of the left wrist away? Yeah, it’s infuriating to behold the needlessly slow.

The guys who created Fluxbox understand this, and they’ve built in functionality that dramatically saves you time. This is my Keys file. It’s actually not all that huge compared to some I’ve seen. Note that the damned useless windows keys are no longer useless and are just another modifier key like Control and Alternate. You know those eleven aterms of mine? Well opening one of them is as simple as the windows (Super) plus a number, or Super+a for the eleventh one. Super+f opens a new Firefox window. Super+k kills the current window/process while Super+c just closes it normally. Alt+Tab switches between windows, and Super+Tab switches between desktops. Add the Shift key to either of those key combinations and they cycle in reverse order. I even have one for going into a screensaver lock (xlock), and another will shut off my monitors by sending a DPMS shutoff command.

One of the most often used are the various resizing and repositioning keyboard shortcuts. Almost daily, I’ll open a work aterm with a Super+a, and immediately do an Alt+Super+LeftArrow which moves it to the left edge of the screen, then Alt+Super+UpArrow which moves it to the top. In three strokes I’ve started a shell and moved it out of the way. A keypress further and I’ve opened another work terminal in the default position (center of the screen) for primary use; the other is for backup, often open to man pages or logs. Other key combinations move or resize by 20 or so pixels. Others maximize horizontally for me to read something easier, and then sends it back to the size it was before. Or maximize and then back.

The speed with which I can move things around, flip between workspaces, execute one app, close it, and then flip back to another is incredible. It was this sort of power that I always wanted out of a system, and Fluxbox makes phenomenally simple to set up and use. Add to that the excellent handling of default application positioning and other states, and you’ve got the recipe for working without having to waste time with simple appearance/usability issues. You focus on doing the things you want to be doing rather than being forced to repeat the same ridiculous actions over and over. It’s a beautifully streamlined interface.

Next page: Other Stuff and Conclusion

Pages: 1 2 3 4 5

• aterm
• bashrc
• desktop
• Fluxbox
• fluxbox apps
• fluxbox configuration
• fluxbox keys
• fluxbox startup
• fluxbox-generate_menu
• HOWTO
• screenshots
• Slackware
• styles
• tabbed windowing
• themes
• workspace
• X
• Xdefaults
• xinitrc
• Xmodmap