Fluxbox In-Depth: Mad Customization And Other Tips


Firstly, all those cool transparent terminals you see are usually aterms (or eterms). These are extremely lightweight (non-UTF8), highly customizable terminals. Though not a part of the Fluxbox project, the question of how to get these cool-looking terminals often goes right along with the adoption of Fluxbox, so I’ve decided to cover them by describing my setup.

I have 11 predefined terminals of varying sizes and locations that start in specific directories with various commands issued. For example, aterm0 is a full screen terminal that opens with htop started, so if I think I’ve got a runaway process I just use the keyboard shortcut, and instantly there’s the culprit. The 7 terminals that open in my first workspace upon starting Fluxbox are each separately defined. I also have a fairly large aterm that I use for general purpose command line work.

I define all of these in my my .bashrc, and I do this by two methods: by bash shell aliases, and by creating single-line bash scripts that contain the aterm commands. The aliases let me start these aterms from the command line of existing terminals. The scripts let me start these aterms from other applications and the Fluxbox root menu. The execution of initial commands when these aterms are started is controlled through a case statement that checks the aterm’s terminal name definied in $TERM which is set in the aterm command by the -tn switch.

Let me describe what is happening in each part of my .bashrc. First, I set each aterm command parameter as a bash script variable, then use those in the commands themselves in order to make the commands more legible, as well as allow me to have notes for each parameter. This is where options like transparency/shading, background color, and font are set. Next, I create the full aterm commands using those parameter variables (and others), and save them into 11 individual variables ($ATX, $AT0… $AT9). It is those 11 variables that I then echo into scripts placed in /usr/local/bin. And those variables are also used as the aliases for this bash shell instance. Note that after I create the scripts the first time, I comment out the echo commands so as to not repeat unnecessary work each time a bash shell is opened: define/create them once and then leave them alone until something changes.

After the definition of the aterm commands, comes the check for whether or not I want to perform any additional commands. The .bashrc file is always run when a new shell is opened, but that does not necessarily mean that I wish to do anything more. For one, I could be within the Linux console (TTY1) without a window manager or X running at all, in this case I don’t want to do anything further, so that is the first test.

The next test is to see which aterm type it is dealing with. This is the reason that I used the -tn switch to name the global system $TERM veriable, and I gave each predefined aterm a different name based on which function it is fullfilling. So for example, the case statement checks to see if it is aterm0; if so it changes directories, and executes /usr/bin/htop. But here you should note that in all cases, I change the $TERM variable back to the default, “xterm”.

This is for the other major test taking place in the case statement: it is checking to see if the aterm is a new window, or if a new bash shell is being opened from within an already existing window (e.g., via su, bash, or even if merely .bashrc is being executed to load new settings). To walk you through it: the first time an aterm is opened the aterm command will set $TERM to “aterm0” (for example), .bashrc will then be run, when it gets to the case, it will see that it is not the console, and then seeing that it has instructions for “aterm0” it will execute the commands there, including changing the $TERM to “xterm”. Later, after I have closed htop, I continue to use the window and su into another user. A new bash shell is started within the existing window, but when .bashrc checks if it should change directories and run htop again, it doesn’t because it is no longer named “aterm0”.

That’s how I set up and use my aterms. If you want you can remove the aterm title bar, the scroll bar, and make it entirely transparent. Or you can put an aterm in the “Slit,” thus putting text on your desktop – which is pretty damn cool. Take a look at this Howto for some more details. I personally keep mine only somewhat transparent so that I can more easily read my terminals. It’s really a trade off between coolness and readability, and the readability is very dependent on your background image, font, and font colors. When I change backgrounds I frequently change my aterm settings as well.

I know that aterms are not part of Fluxbox, but to me the two go hand-in-hand. I’ve spent quite a bit of time figuring and perfecting a method to get aterms of various sizes at a whim as well as upon startup. If you decide to toy around with your own aterm setup, this will probably be the biggest time sink by far as you tweak and tweak and tweak, compared to setting up Fluxbox. Feel free to use my method and good luck.

Next page: Fluxbox Startup

16 thoughts on “Fluxbox In-Depth: Mad Customization And Other Tips

  1. Great writeup, Pat. I’m actually going to have to play around with the Fluxbox Apps file… there’s a lot of cool functionality in that particular file that I’m just still not using, and I could get used to some of those things really quick.

    You’ve already spoiled me with the stuff I’ve lifted from your Keys file (particularly the window sizing and movement key bindings… those are really handy, and I’ve only been using them for a few weeks).

  2. Pingback: Links 04/08/2009: GNOME Dropping Icon Clutter, KDE 4.3 Finally Liked by SJVN | Boycott Novell
  3. “So when I restart my computer or even just a program, I absolutely detest having to resize and relocate windows to the way I had them before the restart”

    Have you ever tried devilspie/gdevilspie(gui)? it let’s me do that and a lot more in xfce. I’m sure you’ll like it…

    check them out:



  4. Good post. You’ve inspired me to tweak my own FluxBox configuration a bit more. I’m going to have to play with the startup and apps files, and of course the keys file. 🙂

  5. Thanks. Glad I could help. My keys file really isn’t that complicated, but you can google and find all sorts of amazing example files. Have fun!

  6. Pingback: Fluxbox and dockapps « The Linux Critic
  7. nice guide to Fluxbox, really.. I definitely share your enthusiasm about Flux’s speed, lightweight-ness, and ease of configuration/customization!

  8. Pingback: Mint Enlightenment « The Linux Critic
  9. Hi! Just want to say thank you. I’m trying out fluxbox and thanks to what you wrote and generously shared, I was able to make out what to do with it! Now I’m loving it! Keep up the good work. Take care and God bless.

  10. Quick suggestion: If you like Firefox, try Swiftfox, a speed-optimized Firefox for Linux only! While it hasn’t been updated to version 4 yet, it runs much faster than FF and goes well with Fluxbox, plus it has access to all of the extensions and add-ons as FF! Also, if you’re wanting to use a minimalistic file manager (which most Fluxboxians are), try PCManFM. It’s quick, it’s easy, and it gets the job done well.

  11. Hello Patrick,

    Tnaks for this great tutorial !

    I never found the answer to my question on the launch of programs on several desktops at fluxbox startup :
    Is it possible to launch, for example, appli#1 on desktop#2, appli#2 on #desktop#4, appli#3 on desktop #3 and so on ?

    (desktop#n = virtual desktop in fluxbox)

    If it was possible, could you tell us how to do in the startup file, to obtain this result ?

    Thanks in advance !

  12. You all are welcome. Glad to see this is still helpful even if some of the links are broken. =D But I knew that would happen eventually.

  13. @Guillaume
    I know it’s been months and you’ve probably found your answer already, but I’ll respond anyway. What you’re asking is really two different questions.

    First, to launch apps on startup, see here:

    Second, to get them to open on the different desktops (fluxbox calls them “workspaces”) you can edit the Apps file to include “[Workspace] {4}” under that app (change the number). You don’t have to edit it by hand though. If you run the app you want on the workspace you want, right-click the app’s titlebar, go down to Remember, and check the box next to Workspace. This will add the line to the Apps file for you.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s