Imported nx-X11-3.1.0-1.tar.gznx-X11/3.1.0-1

Summary: Imported nx-X11-3.1.0-1.tar.gz
Keywords:

Imported nx-X11-3.1.0-1.tar.gz
into Git repository

1 files changed, 264 insertions, 0 deletions

diff --git a/nx-X11/programs/Xserver/hw/xnest/Xnest.man b/nx-X11/programs/Xserver/hw/xnest/Xnest.man
new file mode 100644
index 000000000..131c224f2
--- /dev/null
+++ b/nx-X11/programs/Xserver/hw/xnest/Xnest.man
@@ -0,0 +1,264 @@
+.\" $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
+