The X server can store various configuration values for client programs
so they are readily available when needed. If the application supports this,
it will use these as defaults whenever that program is invoked. These are
known as "Resources", and are often used to define user preferences
on a per application basis for fonts, colors, screen placement (geometry) and
various other attributes. This makes it easy to customize applications.
Resources are specified as text strings (e.g. Netscape*blinkingEnabled:
False) that can be read from disk in various places when
X is starting, or even interactively defined on the
command line. Program components are named in a hierarchical fashion, with
each object in the hierarchy identified by a class as well as an instance
name. At the top level of the hierarchy is the class and instance name of the
application itself. Typically, the class name of the application is the
same as the program name, but with the first letter capitalized (e.g. Vim or
Emacs) although some programs that begin with the letter "X"
also capitalize the second letter for historical reasons (e.g. XTerm).
Each definition will specify a class (or instance), with corresponding
resource and value. Below this in the hierarchy are the various attributes
that make up the definable aspects of the application.
Traditionally, most X programs were configured
this way. This is not as true today with the advent of Desktop Environments
which often have their own configuration mechanisms.
As an example, say we prefer to run xterm with a blue
background. So if we run it from the command line, we would run it as:
If this is our preference, it would be easier to put this preference in a
file somewhere, and have the system use our preference. That way whenever we
started xterm, it would use our preferred value, and we
wouldn't need the command line options (unless as an override).
The basic X resource syntax is expressed like:
<program><binding><widget><binding><widget><...><resource>:<value>
|
Which, in real life, typically looks something like:
xterm*fontMenu*background: darkblue
|
It should be obvious what this does. The use of "*" in the
definition, is called a "loose binding" and acts as a
wild-card. Meaning there may be gaps in the widget hierarchy. For instance:
xterm*background: darkblue
|
This would also give a dark blue background for the xterm
fontMenu, but also any other xterm properties that also have a
"background" attribute (e.g. window background, etc), no matter
where they may be in the widget hierarchy. Similarly:
This would define the background for any and all programs that support it -- not just
xterm. Using a "." in place of a
"*" would be more precise, and will not allow for wild-card gaps
in the hierarchy. Also, the application must support the particular widget
attribute. "Background" is a fairly safe bet, but many
applications will have more specialized resources that are not so obvious. It
is best to check local documentation (man pages, etc), or see if an
application has an included examples. For instance, Netscape
generally comes with an Netscape.ad file that has an extensive
set of resource definitions that can be customized.
X resources are typically stored in more than one
place (see below) and are processed by the xrdb command (see man page).
One way of storing preferred application resources is via files named for the
application in an "app-defaults" directory. For instance, on my
system, these are in /usr/X11R6/lib/X11/app-defaults/,
though this may vary according to options your vendor has chosen. This
directory contains a number of files for such well known
X applications as xterm,
xclock, xcalc,
xload, and so on. All in all, it is a relatively small
number of applications in the overall scheme of things. So not all
applications use this scheme. In fact, most do not.
Each file will contain resource definitions for that application. The X
server loads these by itself during start up. A brief example from
XTerm-color:
! $XFree86$
#include "XTerm"
*VT100*colorMode: on
*VT100*dynamicColors: on
! Uncomment this use color for underline attribute
!*VT100*colorULMode: on
!*VT100*underLine: off
! Uncomment this to use color for the bold attribute
!*VT100*colorBDMode: on
*VT100*color0: black
*VT100*color1: red3
*VT100*color2: green3
*VT100*color3: yellow3
*VT100*color4: blue3
*VT100*color5: magenta3
*VT100*color6: cyan3
*VT100*color7: gray90
*VT100*color8: gray30
*VT100*color9: red
*VT100*color10: green
*VT100*color11: yellow
*VT100*color12: blue
*VT100*color13: magenta
*VT100*color14: cyan
*VT100*color15: white
*VT100*colorUL: yellow
*VT100*colorBD: white
|
This is mostly various color definitions. The application classname is not
explicitly stated, and is assumed from the filename. So think of each line as
starting: XTerm-color*. Also, notice at the top, the
#include "XTerm" line, which "includes" the
resource definitions for XTerm, a much longer file with a
more diverse set of definitions. (Not included due to length, but worth
looking at.) These files provide system wide defaults, and generally
speaking, would not normally be edited by the user.
Another common method of reading in resource preferences, is with an
Xdefaults file. Or, sometimes the naming
scheme may be Xresources instead. This may exist as a
system wide file, such as /etc/X11/Xresources.
Of course, the user is free to create a personal version in his home
directory, e.g. ~/.Xdefaults. The user's version will
over-ride any system wide settings, and will remain after system upgrades.
Obviously, this is the place to put your own preferences.
Xresources files are read into the resource database
with the xrdb command. Example:
xrdb -merge ~/.Xresources
|
This can be done interactively at the command line, or placed in a script and
run automatically as the X session is started. In
the case of system wide files, this should be taken care of by the vendor
supplied start up scripts. Generally, such scripts will also check the user's
home directory as well (see the xinitrc example above).
So probably all that need be done, is to create the file with a text editor.
Here's an example to illustrate a very few of the many things that might
be done with an .Xdefaults file:
! This is a comment ;-)
#ifdef COLOR
*customization: -color
#endif
!! Let's cast a wide net, for any app supporting these
! Blink instead of beeping
*visualBell: True
*scrollTtyOutput: False
*scrollKey: True
! See Netscape.ad for many settable resources
Netscape*noAboutSplash: True
Netscape*documentFonts.sizeIncrement: 5
Netscape*documentFonts.xResolution*iso-8859-1: 120
Netscape*documentFonts.yResolution*iso-8859-1: 120
netscape-navigator*geometry: 960x820+240+140
emacs*Background: DarkBlue
emacs*Foreground: Wheat
emacs*pointerColor: Orchid
emacs*cursorColor: Orchid
emacs*bitmapIcon: on
emacs*font: 10x20
! GVim colors, etc
!! GTK versions of gvim will not use all these.
Vim*useSchemes: all
Vim*sgiMode: true
Vim*useEnhancedFSB: true
Vim.foreground: Black
!Vim.background: lightyellow2
Vim*background: white
! geometry: width x height
Vim.geometry: 88x40
Vim*font: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso8859-15-*5
Vim*menuBackground: yellow
Vim*menuForeground: black
rxvt*backspacekey: ^?
rxvt*background: Black
rxvt*foreground: wheat
rxvt*cursorColor: Orchid
rxvt*geometry: 100x18+40+300
rxvt*title: Linux
rxvt*reverseVideo: false
!rxvt*backgroundPixmap: ~/penguinitis.xpm
rxvt*scrollBar: true
rxvt*reverseWrap: true
rxvt*font: -*-lucidatypewriter-medium-*-*-*-14-*-*-*-*-*-*-*
rxvt*fullCursor: true
rxvt*saveLines: 1500
rxvt*menu: ~/rxvt.menu
XTerm*saveLines: 1500
! Do not clear the screen after the program exits
XTerm*VT100*titeInhibit: true
! Fix up xterm's keybindings
xterm*VT100.translations: #override \
<Key>BackSpace: string(0x7F) \n\
<Key>Insert: string(0x1b) string("[2~")\n\
<Key>Delete: string(0x1b) string("[3~")\n\
<Key>Home: string(0x1b) string("[1~")\n\
<Key>End: string(0x1b) string("[4~")\n\
<Key>Page_Up: string(0x1b) string("[5~")\n\
<Key>Page_Down: string(0x1b) string("[6~")\n\
<KeyPress>Prior : scroll-back(1,page)\n\
<KeyPress>Next : scroll-forw(1,page)
! Ghostview
Ghostview*Font: *-helvetica-bold-r-normal--12-*-*-*-*-*-*
Ghostview*BorderColor: white
Ghostview*Text*Font: rk14
Ghostview*Background: #d9d9d9
!Ghostview*Foreground: white
ghostview.form.pageview.page.background: white
ghostview.form.pageview.page.foreground: black
.ghostview.zoom.form.page.background: white
.ghostview.zoom.form.page.foreground: black
! xscreensaver !
! Time out after 12 minutes, cycle mode after each 2
xscreensaver.timeout: 12
xscreensaver.cycle: 5
! Run low priority, and fade between modes
xscreensaver.nice: 12
xscreensaver.fadeSeconds: 2
XFontsel.menu.options.showUnselectable: False
|
Hopefully, these few examples will give you some ideas to build on.
X does not need to be restarted if
xrdb is used interactively from the command line after
making changes. The effects are immediate.
Resources are sometimes available also as command line options. See below.
Command line options will over-ride any existing resource definitions.
The keyboard and mouse, as well as other possible input devices, are defined
in XF86Config (or XF86Config-4).
There is a keyboard layout that is defined based on the preferred language:
Section "InputDevice"
Identifier "Keyboard0"
Driver "keyboard"
Option "XkbLayout" "us"
EndSection
|
This gives us our default keyboard layout. Valid layout labels are listed in
/usr/X11R6/lib/X11/xkb/symbols. Also, the
setxkbmap utility can be used to change this
interactively.
X is highly customizable, and we can modify the
keyboard and mouse pointer mappings to suit our own preferences. The utility
to do this is xmodmap (see man page). You don't like where
the capslock key is? So move it ;-)
Like xrdb, xmodmap can be run from the
command line. Or, preferred settings can be stored in a file. Typically this
is ~/.Xmodmap, or similar. If your
X start up files don't parse this, then edit as
appropriate so that they do (probably from ~/.xinitrc or
~/.xsession).
You can view your current key and mouse mappings with: xmodmap -pk
-pp |less. This will print out all active "keycode"
values, with corresponding "keysym" values, and any keysym names
that xmodmap knows about (e.g. "BackSpace").
And should also give you an idea of how xmodmap
understands key and mouse events. There are two keysyms per keycode. The
second is the shifted value. XFree86's xev utility can be
used to dump a lot of information on key-presses and mouse events
interactively. Pay attention to the "keycode" value. That is
what you will need to know in order to re-map.
xmodmap is often used to make minor keyboard adjustments,
like proper Backspace/Delete mapping. Or can be used make major adjustments
such as for international mappings. You can only re-map keys and mouse events
-- you cannot assign macros to key events (your Window Manager or Desktop
might have some of this functionality).
Setting up international keyboards in nicely discussed in http://www.linuxdoc.org/HOWTO/mini/Intkeyb/index.html.
Also, a search of http://google.com/linux
will turn up many creative examples.
The man page has many brief examples of various usages. Here is what an
one hypothetical ~/.Xmodmap might look like:
! /home/hal/.Xmodmap, last change 10/03/01
!
! Force backspace to 22 and Delete to 111
keycode 22 = BackSpace
keycode 111 = Delete
!
! My keyboard handles right and left Alt differently. Make the
! Right act like the Left to avoid digital gymnastics.
keycode 63 = Alt_L
keycode 113 = Meta_L
!
! Hard-code the keypad to numeric values as if numlock is always on
! since I never use it for anything else.
keycode 79=7
keycode 80=8
keycode 81=9
keycode 83=4
keycode 84=5
keycode 85=6
keycode 87=1
keycode 88=2
keycode 89=3
keycode 90=0
keycode 91=period
keycode 86 = plus
! deactivate Num_Lock key since we don't need it now.
keycode 77 =
!
! My capslock is next to tab. I hit it by mistake sometimes,
! and don't use it anyway. So make capslock act like Tab.
keycode 66 = Tab
clear lock
!
! Reverse mouse buttons for left-handed people
pointer = 3 2 1
|
As with many XFree86 files, the "!" represents a comment.
Another possible use, is to redefine those annoying "Windows"
keys to something useful. Hopefully this gives an idea of some things one
might want to do to make the keyboard more agreeable to us.
Speaking of the Numlock key, X
will typically disable this when it starts up. No matter how you have the
BIOS set up, or Linux set up before X starts. So the
trick above is one way. There is also a utility available as either
numlockx, or
setnumlock, that can be found on the 'Net, if
your distribution does not include one or the other. This can be put in a
start up file to turn Numlock on automatically if you'd
prefer.
Window Managers and Desktop Environments will also allow customization of the
keyboard and mouse (as long as it is recognized correctly by
X). This may be an easier way to configure certain
customizations.
As mentioned, Linux and Unix make heavy use of three mouse buttons. If a
mouse only has two buttons, then the third (i.e. the middle) button can
be simulated by pressing both buttons simultaneously. This is a
configuration option set in XF86Config as the
"Emulate3Buttons" directive:
Section "InputDevice"
Identifier "Mouse0"
Driver "mouse"
Option "Device" "/dev/mouse"
Option "Protocol" "PS/2"
Option "Emulate3Buttons" "on"
EndSection
|
When all is said and done, a third button is quite handy and I would personally recommend
having one. On wheeled mice, the "wheel" acts as the third
button, if pressed. Many standard wheel mice seem to work with the
"IMPS/2" protocol option.
Specifically, the third button (middle) is the "paste" button in
virtually all Linux applications. Copy and paste works a little different in
Linux. The left button is the copy button. Just hold it down, and drag over
text. It is automatically copied to the X
"clipboard". Then, the middle button will paste from there. A
very simple process. A double-click should copy individual words, and a
triple-click individual lines of text. If for some reason, this does not
work, it is either a poorly implemented application, or a bug of some kind.
Some older versions of Netscape were not
consistent about this, for instance. To paste from the keyboard, this should
be shift+insert.
"Drag and Drop" is not natively supported by
X itself. But, is implemented by some toolkits and
Desktop Environments. One should not expect this to work with non-compliant
applications (i.e non-KDE aware applications in
KDE for example).
