To continue in this theme, there are some pretty powerful things that you can do in your .XDefaults file. Now, I know a lot of you young whipper-snappers are saying “What is an XDefaults file?” or “Hasn't KDE/Gnome made that obsolete?” I don't really know about the latter, all I can say is that I still use them. So lets talk about the former…
The XDefaults file, typically in your home directory named “.XDefaults” is a very old thing. It contains X server resource database entries which can be used to influence the way many programs work. See the man page for “xrdb” for more information about the X server resource database.
Many of the newer programs I don't believe use this interface, which is kind of a shame. Sure, configuration using a dialog is nice, but do we really have to throw away the old to make room for the new? There are still plenty of older programs around that use the X resources, and the one I'm going to talk most about here is “xterm”. Yes, I still use xterm instead of any of the other terms. I'm not a big fan of tabbed terminals or see-through backgrounds, and have configured xterm so that I'm very comfortable with it.
The first thing to realize is that xterm is extremely configurable. You name it, you can probably configure it. Using the XRDB, you can influence settings for xterm, and even for all applications (which use XRBD) at once. You specify application names and sub attributes using a “.” to indicate the next level in the hierarchy and “*” to indicate many levels. For example:
tells all programs set their default font to the font named “10x20”, while:
indicates that only sub-elements of xterm should use that font. The nice thing is that this setting takes effect without having to call the program with special options, though many of the resources have matching command-line parameters (“xterm -font 10x20”).
Here are some of the things I've done with my xterms that I like:
*VT100.Translations: #override <Key>Prior: scroll-back(1,page) \n\ <Key>Next: scroll-forw(1,page) \n \ Shift<Key>Up: scroll-back(1,line) \n \ Shift<Key>Down: scroll-forw(1,line) \n
The above tells xterm that if I press page-up or page-down, it should scroll the display a screen at a time. The default is Shift-page-up/down. However, I also set Shift-up and Shift-down to scroll a single line.
xterm*jumpScroll: true xterm*saveLines: 3000 xterm*scrollBar: false xterm*scrollTtyOutput: false xterm*scrollKey: false
This configures more about the scrolling. I enable jump scrolling on screen updates because it's much faster. This is a hold-over from the days when displays were much slower. The next lines configure the scrolling, saving 3000 lines of history, and making it so that no scroll bar is shown and typing or program output does not cause the window to scroll to the bottom. I often like to review my history and type in new things, so it's an annoyance when it scrolls to the bottom if I type in a file name from the long “ls” output I'm reviewing.
*titeInhibit: true XTerm*colorBDMode: FALSE XTerm*colorULMode: FALSE
I consider these to be annoyances. The first, “tite” (named after the “curses” controls for performing this, is what allows some applications like “vim” to run and then restore the terminal to how it was before you ran the program. I was always annoyed that if I edited something then wanted to run a command I lost the context of what I was editing. This disables it. The next two lines cause prevent bold and underlined characters from showing up in special colors. Particularly annoying since the color used by bold is dark blue, and on a black background it's very difficult to read. I like a dark background.
xterm*loginShell: true xterm*cursorColor: yellow
Finally, I set it so that xterm runs every shell as if it were a login shell, setting up a consistent environment. Lastly, I set my cursor color to yellow.
It's a pretty powerful mechanism which allows you to configure nearly every way that xterm operates. See the man page for for xterm for a full reference to the values available to be configured. If printed, the man page would be around 60 pages long, to give you an idea of how many options are covered.
Also, because it's in the X server, it doesn't matter on what host the applications are running, they all would inherit the right values based on your display. At one point there was even a GUI toolkit which used the XRDB for every aspect of defining the GUI. So, a regular user could influence how the GUI worked, without having to change the code. Better, the application changes would happen across all instances on all systems.
Is it past it's prime? Maybe, but I think it still has some things that are useful and application developers of today can learn from.comments powered by Disqus