diff options
Diffstat (limited to 'nx-X11/programs/Xserver/hw/xnest/Xnest.man')
| -rw-r--r-- | nx-X11/programs/Xserver/hw/xnest/Xnest.man | 264 |
1 files changed, 0 insertions, 264 deletions
diff --git a/nx-X11/programs/Xserver/hw/xnest/Xnest.man b/nx-X11/programs/Xserver/hw/xnest/Xnest.man deleted file mode 100644 index 131c224f2..000000000 --- a/nx-X11/programs/Xserver/hw/xnest/Xnest.man +++ /dev/null @@ -1,264 +0,0 @@ -.\" $Xorg: Xnest.man,v 1.3 2000/08/17 19:53:28 cpqbld Exp $ -.\" Copyright (c) 1993, 1994 X Consortium -.\" -.\" Permission is hereby granted, free of charge, to any person obtaining -.\" a copy of this software and associated documentation files (the -.\" "Software"), to deal in the Software without restriction, including -.\" without limitation the rights to use, copy, modify, merge, publish, -.\" distribute, sublicense, and/or sell copies of the Software, and to -.\" permit persons to whom the Software is furnished to do so, subject to -.\" the following conditions: -.\" -.\" The above copyright notice and this permission notice shall be included -.\" in all copies or substantial portions of the Software. -.\" -.\" THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS -.\" OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF -.\" MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. -.\" IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE FOR ANY CLAIM, DAMAGES OR -.\" OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, -.\" ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR -.\" OTHER DEALINGS IN THE SOFTWARE. -.\" -.\" Except as contained in this notice, the name of the X Consortium shall -.\" not be used in advertising or otherwise to promote the sale, use or -.\" other dealings in this Software without prior written authorization -.\" from the X Consortium. -.\" -.\" $XFree86: xc/programs/Xserver/hw/xnest/Xnest.man,v 1.6 2001/01/27 18:21:00 dawes Exp $ -.\" -.TH XNEST 1 __xorgversion__ -.SH NAME -Xnest \- a nested X server -.SH SYNOPSIS -.B Xnest -[-options] -.SH DESCRIPTION -\fIXnest\fP is a client and a server. \fIXnest\fP is a client of the -real server which manages windows and graphics requests on its behalf. -\fIXnest\fP is a server to its own clients. \fIXnest\fP manages -windows and graphics requests on their behalf. To these clients -\fIXnest\fP appears to be a conventional server. -.SH OPTIONS -\fIXnest\fP supports all standard options of the sample server -implementation. For more details, please see the manual page on your -system for \fIXserver\fP. The following additional arguments are -supported as well. -.TP 4 -.B \-display \fIstring\fP -This option specifies the display name of the real server that -\fIXnest\fP should try to connect with. If it is not provided on the -command line \fIXnest\fP will read the \fIDISPLAY\fP environment -variable in order to find out the same information. -.TP 4 -.B \-sync -This option tells \fIXnest\fP to synchronize its window and graphics -operations with the real server. This is a useful option for -debugging, but it will slow down the performance considerably. It -should not be used unless absolutely necessary. -.TP 4 -.B \-full -This option tells \fIXnest\fP to utilize full regeneration of real -server objects and reopen a new connection to the real server each -time the nested server regenerates. The sample server implementation -regenerates all objects in the server when the last client of this -server terminates. When this happens, \fIXnest\fP by default -maintains the same top level window and the same real server -connection in each new generation. If the user selects full -regeneration, even the top level window and the connection to the real -server will be regenerated for each server generation. -.TP 4 -.B \-class \fIstring\fP -This option specifies the default visual class of the nested server. -It is similar to the \fI-cc\fP option from the set of standard options -except that it will accept a string rather than a number for the -visual class specification. The string must be one of the following -six values: \fIStaticGray\fP, \fIGrayScale\fP, \fIStaticColor\fP, -\fIPseudoColor\fP, \fITrueColor\fP, or \fIDirectColor\fP. If both, -\fI-class\fP and \fI-cc\fP options are specified, the last instance of -either option assumes precedence. The class of the default visual of -the nested server need not be the same as the class of the default -visual of the real server; although, it has to be supported by the -real server. See \fIxdpyinfo\fP for a list of supported visual -classes on the real server before starting \fIXnest\fP. If the user -chooses a static class, all the colors in the default colormap will be -preallocated. If the user chooses a dynamic class, colors in the -default colormap will be available to individual clients for -allocation. -.TP 4 -.B \-depth \fIint\fP -This option specifies the default visual depth of the nested server. -The depth of the default visual of the nested server need not be the -same as the depth of the default visual of the real server; although, -it has to be supported by the real server. See \fIxdpyinfo\fP for a -list of supported visual depths on the real server before starting -\fIXnest\fP. -.TP 4 -.B \-sss -This option tells \fIXnest\fP to use the software screen saver. By -default \fIXnest\fP will use the screen saver that corresponds to the -hardware screen saver in the real server. Of course, even this screen -saver is software generated since \fIXnest\fP does not control any -actual hardware. However, it is treated as a hardware screen saver -within the sample server code. -.TP 4 -.B \-geometry \fIWxH+X+Y\fP -This option specifies geometry parameters for the top level -\fIXnest\fP windows. These windows corresponds to the root windows of -the nested server. The width and height specified with this option -will be the maximum width and height of each top level \fIXnest\fP -window. \fIXnest\fP will allow the user to make any top level window -smaller, but it will not actually change the size of the nested server -root window. As of yet, there is no mechanism within the sample -server implementation to change the size of the root window after -screen initialization. In order to do so, one would probably need to -extend the X protocol. Therefore, it is not likely that this will be -available any time soon. If this option is not specified \fIXnest\fP -will choose width and height to be 3/4 of the dimensions of the root -window of the real server. -.TP 4 -.B \-bw \fIint\fP -This option specifies the border width of the top level \fIXnest\fP -window. The integer parameter must be a positive number. The default -border width is 1. -.TP 4 -.B \-name \fIstring\fP -This option specifies the name of the top level \fIXnest\fP window. -The default value is the program name. -.TP 4 -.B \-scrns \fIint\fP -This option specifies the number of screens to create in the nested -server. For each screen, \fIXnest\fP will create a separate top level -window. Each screen is referenced by the number after the dot in the -client display name specification. For example, \fIxterm -display -:1.1\fP will open an \fIxterm\fP client in the nested server with the -display number \fI:1\fP on the second screen. The number of screens -is limited by the hard coded constant in the server sample code which -is usually 3. -.TP 4 -.B \-install -This option tells \fIXnest\fP to do its own colormap installation by -bypassing the real window manager. For it to work properly the user -will probably have to temporarily quit the real window manager. By -default \fIXnest\fP will keep the nested client window whose colormap -should be installed in the real server in the -\fIWM\_COLORMAP\_WINDOWS\fP property of the top level \fIXnest\fP -window. If this colormap is of the same visual type as the root -window of the nested server, \fIXnest\fP will associate this colormap -with the top level \fIXnest\fP window as well. Since this does not -have to be the case, window managers should look primarily at the -\fIWM\_COLORMAP\_WINDOWS\fP property rather than the colormap -associated with the top level \fIXnest\fP window. Unfortunately, -window managers are not very good at doing that yet so this option -might come in handy. -.TP 4 -.B \-parent \fIwindow_id\fP -This option tells \fIXnest\fP to use the \fIwindow_id\fP as the -root window instead of creating a window. This option is used -by the xrx xnestplugin. -.SH USAGE -Starting up \fIXnest\fP is as simple as starting up \fIxclock\fP from -a terminal emulator. If a user wishes to run \fIXnest\fP on the same -workstation as the real server, it is important that the nested server -is given its own listening socket address. Therefore, if there is a -server already running on the user's workstation, \fIXnest\fP will -have to be started up with a new display number. Since there is -usually no more than one server running on a workstation, specifying -\fIXnest :1\fP on the command line will be sufficient for most users. -For each server running on the workstation the display number needs to -be incremented by one. Thus, if you wish to start another -\fIXnest\fP, you will need to type \fIXnest :2\fP on the command line. -.PP -To run clients in the nested server each client needs to be given the -same display number as the nested server. For example, \fIxterm --display :1\fP will start up an \fIxterm\fP in the first nested server -and \fIxterm -display :2\fP will start an \fIxterm\fP in the second -nested server from the example above. Additional clients can be -started from these \fIxterm\fPs in each nested server. -.SH XNEST AS A CLIENT -\fIXnest\fP behaves and looks to the real server and other real -clients as another real client. It is a rather demanding client, -however, since almost any window or graphics request from a nested -client will result in a window or graphics request from \fIXnest\fP to -the real server. Therefore, it is desirable that \fIXnest\fP and the -real server are on a local network, or even better, on the same -machine. As of now, \fIXnest\fP assumes that the real server supports -the shape extension. There is no way to turn off this assumption -dynamically. \fIXnest\fP can be compiled without the shape extension -built in, and in that case the real server need not support it. The -dynamic shape extension selection support should be considered in -further development of \fIXnest\fP. -.PP -Since \fIXnest\fP need not use the same default visual as the the real -server, the top level window of the \fIXnest\fP client always has its -own colormap. This implies that other windows' colors will not be -displayed properly while the keyboard or pointer focus is in the -\fIXnest\fP window, unless the real server has support for more than -one installed colormap at any time. The colormap associated with the -top window of the \fIXnest\fP client need not be the appropriate -colormap that the nested server wants installed in the real server. -In the case that a nested client attempts to install a colormap of a -different visual from the default visual of the nested server, -\fIXnest\fP will put the top window of this nested client and all -other top windows of the nested clients that use the same colormap -into the \fIWM\_COLORMAP\_WINDOWS\fP property of the top level -\fIXnest\fP window on the real server. Thus, it is important that the -real window manager that manages the \fIXnest\fP top level window -looks at the \fIWM\_COLORMAP\_WINDOWS\fP property rather than the -colormap associated with the top level \fIXnest\fP window. Since most -window managers appear to not implement this convention properly as of -yet, \fIXnest\fP can optionally do direct installation of colormaps -into the real server bypassing the real window manager. If the user -chooses this option, it is usually necessary to temporarily disable -the real window manager since it will interfere with the \fIXnest\fP -scheme of colormap installation. -.PP -Keyboard and pointer control procedures of the nested server change -the keyboard and pointer control parameters of the real server. -Therefore, after \fIXnest\fP is started up, it will change the -keyboard and pointer controls of the real server to its own internal -defaults. Perhaps there should be a command line option to tell -\fIXnest\fP to inherit the keyboard and pointer control parameters -from the real server rather than imposing its own. This is a future -consideration. -.SH XNEST AS A SERVER -\fIXnest\fP as a server looks exactly like a real server to its own -clients. For the clients there is no way of telling if they are -running on a real or a nested server. -.PP -As already mentioned, \fIXnest\fP is a very user friendly server when -it comes to customization. \fIXnest\fP will pick up a number of -command line arguments that can configure its default visual class and -depth, number of screens, etc. In the future, \fIXnest\fP should read -a customization input file to provide even greater freedom and -simplicity in selecting the desired layout. Unfortunately, there is -no support for backing store and save under as of yet, but this should -also be considered in the future development of \fIXnest\fP. -.PP -The only apparent intricacy from the users' perspective about using -\fIXnest\fP as a server is the selection of fonts. \fIXnest\fP -manages fonts by loading them locally and then passing the font name -to the real server and asking it to load that font remotely. This -approach avoids the overload of sending the glyph bits across the -network for every text operation, although it is really a bug. The -proper implementation of fonts should be moved into the \fIos\fP -layer. The consequence of this approach is that the user will have to -worry about two different font paths - a local one for the nested -server and a remote one for the real server - since \fIXnest\fP does -not propagate its font path to the real server. The reason for this -is because real and nested servers need not run on the same file -system which makes the two font paths mutually incompatible. Thus, if -there is a font in the local font path of the nested server, there is -no guarantee that this font exists in the remote font path of the real -server. \fIXlsfonts\fP client, if run on the nested server will list -fonts in the local font path and if run on the real server will list -fonts in the remote font path. Before a font can be successfully -opened by the nested server it has to exist in local and remote font -paths. It is the users' responsibility to make sure that this is the -case. -.SH BUGS -Won't run well on servers supporting different visual depths. -Still crashes randomly. Probably has some memory leaks. -.SH AUTHOR -Davor Matic, MIT X Consortium - |