Fluxbox In-Depth: Mad Customization And Other Tips

Aterms

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

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