Top Document: comp.windows.x.intrinsics Frequently Asked Questions (FAQ) Previous Document: 19. What changed from R3 to R4 to R5? Next Document: 21. What order are callbacks executed in? See reader questions & answers on this topic! - Help others by sharing your knowledge ---------------------------------------------------------------------- The resources of a widget are filled in from the following places (from highest priority to lowest priority): 1. Args passed at creation time. 2. Command line arguments. 3. User's per host defaults file 4. User's defaults file. 5. User's per application default file. 6. System wide per application default file. Note that 2-6 are read only once on application startup. The result of steps 3-6 is a single resource database used for further queries. The per host defaults file contains customizations for all applications executing on a specific computer. This file is either specified with the XENVIRONMENT environment variable or if that is not set then the file $HOME/.Xdefaults-<host> is used. The user defaults file is either obtained from the RESOURCE_MANAGER property on the root window of the display or if that is not set then the file $HOME/.Xdefaults is used. Typically, the program "xrdb" is used to set the RESOURCE_MANAGER property. Please note that this should be kept relatively small as each client that connects to the display must transfer the property. A size of around 1-3KByte is reasonable. Some toolkits may track changes to the RESOURCE_MANAGER but most do not. A user may have many per application default files containing customizations specific to each application. The intrinsics are quite flexible on how this file is found. Read the next part that describes the various environment variables and how they effect where this file is found. The system wide per application default files are typically found in /usr/lib/X11/app-defaults. If such a file is not found then the fallback resources are used. The intrinsics are quite flexible on how this file is found. Read the next part that describes the various environment variables and how they effect where this file is found. [Thanks to Oliver Jones (oj@pictel.com) for the following, 6/92] You can use several environment variables to control how resources are loaded for your Xt-based programs -- XFILESEARCHPATH, XUSERFILESEARCHPATH, and XAPPLRESDIR. These environment variables control where Xt looks for application-defaults files as an application is initializing. Xt loads at most one app-defaults file from the path defined in XFILESEARCHPATH and another from the path defined in XUSERFILESEARCHPATH. Set XFILESEARCHPATH if software is installed on your system in such a way that app-defaults files appear in several different directory hierarchies. Suppose, for example, that you are running Sun's Open Windows, and you also have some R4 X applications installed in /usr/lib/X11/app-defaults. You could set a value like this for XFILESEARCHPATH, and it would cause Xt to look up app-defaults files in both /usr/lib/X11 and /usr/openwin/lib (or wherever your OPENWINHOME is located): setenv XFILESEARCHPATH /usr/lib/X11/%T/%N:$OPENWINHOME/lib/%T/%N The value of this environment variable is a colon-separated list of pathnames. The pathnames contain replacement characters as follows (see XtResolvePathname()): %N The value of the filename parameter, or the application's class name. %T The value of the file "type". In this case, the literal string "app-defaults" %C customization resource (R5 only) %S Suffix. None for app-defaults. %L Language, locale, and codeset (e.g. "ja_JP.EUC") %l Language part of %L (e.g. "ja") %t The territory part of the display's language string %c The codeset part of the display's language string Let's take apart the example. Suppose the application's class name is "Myterm". Also, suppose Open Windows is installed in /usr/openwin. (Notice the example omits locale-specific lookup.) /usr/lib/X11/%T/%N means /usr/lib/X11/app-defaults/Myterm $OPENWINHOME/lib/%T/%N means /usr/openwin/lib/app-defaults/Myterm As the application initializes, Xt tries to open both of the above app-defaults files, in the order shown. As soon as it finds one, it reads it and uses it, and stops looking for others. The effect of this path is to search first in /usr/lib/X11, then in /usr/openwin. Let's consider another example. This time, let's set XUSERFILESEARCHPATH so it looks for the file Myterm.ad in the current working directory, then for Myterm in the directory ~/app-defaults. setenv XUSERFILESEARCHPATH ./%N.ad:$HOME/app-defaults/%N The first path in the list expands to ./Myterm.ad. The second expands to $HOME/app-defaults/Myterm. This is a convenient setting for debugging because it follows the Imake convention of naming the app-defaults file Myterm.ad in the application's source directory, so you can run the application from the directory in which you are working and still have the resources loaded properly. NOTE: when looking for app-default files with XUSERFILESEARCHPATH, for some bizarre reason, neither the type nor file suffix is defined so %T and %S are useless. With R5, there's another twist. You may specify a customization resource value. For example, you might run the "myterm" application like this: myterm -xrm "*customization: -color" If one of your pathname specifications had the value "/usr/lib/X11/app-defaults/%N%C" then the expanded pathname would be "/usr/lib/X11/app-defaults/Myterm-color" because the %C substitution character takes on the value of the customization resource. The default XFILESEARCHPATH, compiled into Xt, is: /usr/lib/X11/%L/%T/%N%C:\ (R5) /usr/lib/X11/%l/%T/%N%C:\ (R5) /usr/lib/X11/%T/%N%C:\ (R5) /usr/lib/X11/%L/%T/%N:\ /usr/lib/X11/%l/%T/%N:\ /usr/lib/X11/%T/%N (Note: some sites replace /usr/lib/X11 with a ProjectRoot in this batch of default settings.) The default XUSERFILESEARCHPATH, also compiled into Xt, is <root>/%L/%N%C:\ (R5) <root>/%l/%N%C:\ (R5) <root>/%N%C:\ (R5) <root>/%L/%N:\ <root>/%l/%N:\ <root>/%N: <root> is either the value of XAPPLRESDIR or the user's home directory if XAPPLRESDIR is not set. If you set XUSERFILESEARCHPATH to some value other than the default, Xt ignores XAPPLRESDIR altogether. Notice that the quick and dirty way of making your application find your app-defaults file in your current working directory is to set XAPPLRESDIR to ".", a single dot. In R3, all this machinery worked differently; for R3 compatibilty, many people set their XAPPLRESDIR value to "./", a dot followed by a slash. User Contributions:Top Document: comp.windows.x.intrinsics Frequently Asked Questions (FAQ) Previous Document: 19. What changed from R3 to R4 to R5? Next Document: 21. What order are callbacks executed in? Single Page [ Usenet FAQs | Web FAQs | Documents | RFC Index ] Send corrections/additions to the FAQ Maintainer: ware@cis.ohio-state.edu
Last Update March 27 2014 @ 02:11 PM
|
Comment about this article, ask questions, or add new information about this topic: