Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
Let The Music Play: Join EFF Today

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents
Up to --> Linux Tutorial

· The X Windowing System
· Configuring the X-Windows Server
· The Basics of X
· Resources
· Colors
· Displaying Clients
· Fonts
· The Window Manager
· Remote Access

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Recommend Us
Surveys

Features
HOWTOs
News
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 207 guest(s) and 3 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  
Linux Tutorial - The X Windowing System - Resources
  The Basics of X ---- Colors  


Resources

If we wanted, we also could have included the geometry along with the colors, which would give us a command that is almost too long for the screen. Even now it is a long command that takes a long time to type in, and you can easily make mistakes. One solution would be to write everything in a shell script and start that script instead of typing everything on the command line.

The nice thing is we don't have to do this. X provides a mechanism to change the appearance and sometimes the behavior of a client to fit our personal preferences. This is the concept of a resource. Up to now, we have specified the resource from the command line, such as foreground color and geometry. However, there are resource files that we can edit to change the default characteristics of a given client.

Resource files for most applications are found in /usr/lib/X11/app-defaults. The general form of the resource specification is

appname*subname*subsubname...:value

The application is the name of the program you are starting,usually with the first letter capitalized. Note the word "usually." I don't know how many times I've tried to change a resource and not have it work, only to find out that this one applications name is written in lowercase. In the case of the files in /usr/lib/X11/app-defaults, no appname is necessary because there is one file for each client and X knows what client is meant when it reads these files. If set, X will search the path specified by the XFILESEARCHPATH variable for the resource information.

Unless you want to change the system defaults, I suggest that you leave these files alone. Instead, you can create a user- or machine-specific resource file. Normally, this is $HOME/.Xdefaults--hostname, where hostname is the name of the host to which these resource specifications apply. If the .Xdefaults file is to apply to the local host, you can omit the hostname. If you want to specify an alternative file, you can use the ENVIRONMENT variable.

These resources are organized into classes, which enables you to set groups of individual resources all at once. Individual resources are referred to as an instance. By convention,the class name begins with an uppercase letter and the instance begins with a lowercase letter. We can generally say that a resource (both class and instance)is named for the aspect of appearance that it controls. For example, the class called Foreground sets the foreground color. An instance of the Foreground class would be specified with a lowercase "F": foreground. Keep in mind that different parts of the clients are affected by the class Foreground, such as the text color, cursor color, and pointer color.

Basically all applications have resources. In each case, the class name has an initial capital. Examples of this are

background

window background color

border Width

width in pixels of the window border

border Color

windowborder color

foreground

window foreground color

The distinction between classes and instances is very useful if you want to set several resources at once. For example, if you define the foreground color for all aspects of the XTerm, the resource definition would look like this:

XTerm*Foreground: blue

This would be equivalent to

XTerm*foreground: blue XTerm*cursorColor: blue XTerm*pointerColor: blue

This means that the foreground color of text, cursor, and pointer are all blue. If we then defined the pointerColor instance to be something else, only it changes. For example, if we made the following definition

XTerm*pointerColor: red

the color is now red, although all the others remain blue.

Although the asterisk is perhaps the most commonly used delimiter, it's not the only one. The asterisk delimiter is used to indicate a loose binding, in which there can be several layers in the object hierarchy. It's easy to think of the asterisk as having the same function as on the command line, that is, as a wild card. Here, the asterisk represents 0 or more intermediate layers between the root object and the resource we are defining.

If there are no intermediate layers between the objects, this referred to as a tight binding. If you wanted this, you could specify the binding with the asterisk because it means 0 or more intermediate levels. However, the symbol used to explicitly specify a tight binding is a dot (.). Because I know that the level just before the pointerColor in the hierarchy is "ansi," I can make the specification like this:

XTerm*.ansi.pointerColor: red

However, because the loose binding specifier (*) can be used any place though the tight binding specifier (.) can be used only when appropriate, it is easier always to use the loose binding specifier.

Both the resource specifications and binding can bring up some conflicts. In the example above, we said to use blue for every foreground color related to the client "XTerm." We also said to use red for the foreground color of pointer. Now this seems like a conflict, which it is. However, in this case, the instance of the pointerColor took precedence over the class of Foreground.

Consider these lines from an .Xdefaults file:

XTerm*Foreground: blue XTerm*pointerColor: red XTerm*ansi.pointerColor: green

We first defined the Foreground class to be blue. Next, we defined the instance of the pointerColor to be red. Both of these are done with loose bindings. We then defined the instance of the pointerColor for an ANSI terminal to be green. Because tight bindings have precedence over loose bindings, the pointer is green.

Taking this one step further, we change the class specification so it contains a tight binding. However, we leave the instance specification a loose binding. So, we end up with these two lines:

XTerm*ansi.Foreground: blue XTerm*pointerColor: red

In this case, there is a tightly bound class specification that is followed by a loosely bound instance specification. When we start the XTerm, the pointer is blue, not red. In general, we can say that the more specific a specification is, the greater the precedence.

There are a limited number of options that we can use from the command line, although there are many more resources that we might want to change. To accommodate a large number of resource without increasing the number of options, we use the -xrm option. For example, if we wanted to change the tty modes of XTerm (what the characters are for erase, delete, quit, etc.), we could do this using the -xrm option and specifying an instance of the TtyModes class. For example, to change the interrupt key from the default of Del to Ctrl+C, the command would look like this:

XTerm -xrm XTerm*ttyModes: intr ^C &

Keep in mind that this resource specification is only valid for this one XTerm that we are starting here. If we wanted it to be valid for all XTerms, we would either change the default in /usr/lib/X11/app-defaults or define the resource in the .Xdefaults file.

 Previous Page
The Basics of X
  Back to Top
Table of Contents
Next Page 
Colors


MoreInfo

Test Your Knowledge

User Comments:


Posted by serutake on June 30, 2014 09:11am:

i think this post is greater post then another because its short but effective and impressive content which give the best knowledge. http://www.2pg.org | http://www.kizi2com.org | http://www.frivolity.info


You can only add comments if you are logged in.

Copyright 2002-2009 by James Mohr. Licensed under modified GNU Free Documentation License (Portions of this material originally published by Prentice Hall, Pearson Education, Inc). See here for details. All rights reserved.
  

There are several different ways to navigate the tutorial.


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
You can choose larger fonts by selecting a different themes.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.10 Seconds