unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (OSF1-V5.1-alpha)
Page:
Section:
Apropos / Subsearch:
optional field



Xnest(1X)							    Xnest(1X)
X11R6									X11R6



NAME

  Xnest	- a nested X server

SYNOPSIS

  Xnest	[-options]

OPTIONS

  Xnest	supports all standard options of the sample server implementation.
  For more details, see	Xdec(1X). The following	additional arguments are sup-
  ported as well.

  -display string
      This option specifies the	display	name of	the real server	that Xnest
      should try to connect with.  If it is not	provided on the	command	line
      Xnest will read the DISPLAY environment variable in order	to find	out
      the same information.

  -sync
      This option tells	Xnest to synchronize its window	and graphics opera-
      tions 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.

  -full
      This option tells	Xnest 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 regen-
      erates all objects in the	server when the	last client of this server
      terminates.  When	this happens, Xnest by default maintains the same top
      level window and the same	real server connection in each new genera-
      tion.  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.

  -class string
      This option specifies the	default	visual class of	the nested server. It
      is similar to the	-cc 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:
      StaticGray, GrayScale, StaticColor, PseudoColor, TrueColor, or
      DirectColor.  If both, -class and	-cc 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 xdpyinfo(1X) for a list of supported visual
      classes on the real server before	starting Xnest.	 If the	user chooses
      a	static class, all the colors in	the default colormap will be preallo-
      cated.  If the user chooses a dynamic class, colors in the default
      colormap will be available to individual clients for allocation.

  -config configuration	file
      Specifies	the name of a configuration file to use	to configure the
      loadable X nest server.  The default configuration file is
      /usr/var/X11/Xnest.conf

  -depth int
      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 xdpyinfo(1X) for a list
      of supported visual depths on the	real server before starting Xnest.

  -sss
      This option tells	Xnest to use the software screen saver.	 By default
      Xnest 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 Xnest does not control any actual hardware.
      However, it is treated as	a hardware screen saver	within the sample
      server code.

  -geometry W+H+X+Y
      This option specifies geometry parameters	for the	top level Xnest	win-
      dows.  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 Xnest window.	Xnest 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 Xnest will choose	width and height to be 3/4 of
      the dimensions of	the root window	of the real server.

  -bw int
      This option specifies the	border width of	the top	level Xnest window.
      The integer parameter must be a positive number.	The default border
      width is 1.

  -name	string
      This option specifies the	name of	the top	level Xnest window. The
      default value is the program name.

  -scrns int
      This option specifies the	number of screens to create in the nested
      server.  For each	screen,	Xnest will create a separate top level win-
      dow.  Each screen	is referenced by the number after the dot in the
      client display name specification.  For example, xterm -display :1.1
      will open	an xterm client	in the nested server with the display number
      :1 on the	second screen.	The number of screens is limited by the	hard
      coded constant in	the server sample code which is	usually	3.

  -install
      This option tells	Xnest to do its	own colormap installation by bypass-
      ing the real window manager.  For	it to work properly the	user will
      probably have to temporarily quit	the real window	manager.  By default
      Xnest will keep the nested client	window whose colormap should be
      installed	in the real server in the WM_COLORMAP_WINDOWS property of the
      top level	Xnest window.  If this colormap	is of the same visual type as
      the root window of the nested server, Xnest will associate this color-
      map with the top level Xnest window as well.  Since this does not	have
      to be the	case, window managers should look primarily at the
      WM_COLORMAP_WINDOWS property rather than the colormap associated with
      the top level Xnest window.  Unfortunately, window managers are not
      very good	at doing that yet so this option might come in handy.







DESCRIPTION

  Xnest	is a client and	a server.  Xnest is a client of	the real server	which
  manages windows and graphics requests	on its behalf.	Xnest is a server to
  its own clients.  Xnest manages windows and graphics requests	on their
  behalf.  To these clients Xnest appears to be	a conventional server.

  The Xnest command supports the run-time loading and execution	of X nest
  server libraries on Tru64 UNIX platforms. The	command	loads appropriate
  libraries installed on the workstation and can be configured to use any or
  all of the extension libraries available on your workstation.

USAGE

  Starting up Xnest is as simple as starting up	xclock from a terminal emula-
  tor.	If a user wishes to run	Xnest 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, Xnest will have to be started up with a new display
  number.  Since there is usually no more than one server running on a works-
  tation, specifying Xnest :1 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	Xnest, you
  will need to type Xnest :2 on	the command line.

  To run clients in the	nested server each client needs	to be given the	same
  display number as the	nested server.	For example, xterm -display :1 will
  start	up an xterm in the first nested	server and xterm -display :2 will
  start	an xterm in the	second nested server from the example above.  Addi-
  tional clients can be	started	from these xterms in each nested server.

MODULAR	XNEST SERVER

  When the Xnest command is started, it	uses a set of internal default lists
  of components	to build an X server. It also reads a system configuration
  file (/usr/var/X11/Xnest.conf	or the file specified by the -config option)
  to supplement	or replace components on the lists. The	command	loads all
  system and core components and then transfers	execution to the core com-
  ponents.

  The core components then load	the list of extensions provided	and initial-
  ize the extensions.  Extensions listed in the	configuration file are loaded
  when a client	queries	the extension.	The core components also load any
  font renderers, transport handlers, and authorization	protocol methods
  specified in the configurations.

  The configuration file syntax	is described in	the Xdec(1X) man page.

  The Xnest command searches for libraries using the library_path specified
  in the configuration file or the LD_LIBRARY_PATH environment variable.
  Each component in the	colon separated	path is	searched.  The default search
  path is /usr/shlib/X11:/usr/shlib.

  The default system installation provides a sample configuration file
  /usr/var/X11/Xnest.conf.  It contains	comments and shows examples for	set-
  ting up library lists, library sub-lists, the	library	search path, and sam-
  ple argument lists.



XNEST AS A CLIENT

  Xnest	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 Xnest	to the real server.  Therefore,	it is
  desirable that Xnest and the real server are on a local network, or even
  better, on the same machine.	As of now, Xnest assumes that the real server
  supports the shape extension.	 There is no way to turn off this assumption
  dynamically.	Xnest 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
  Xnest.

  Since	Xnest need not use the same default visual as the real server, the
  top level window of the Xnest	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 Xnest 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	Xnest 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, Xnest 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 WM_COLORMAP_WINDOWS pro-
  perty	of the top level Xnest window on the real server.  Thus, it is impor-
  tant that the	real window manager that manages the Xnest top level window
  looks	at the WM_COLORMAP_WINDOWS property rather than	the colormap associ-
  ated with the	top level Xnest	window.	 Since most window managers appear to
  not implement	this convention	properly as of yet, Xnest 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 Xnest scheme of colormap installation.

  Keyboard and pointer control procedures of the nested	server change the
  keyboard and pointer control parameters of the real server. Therefore,
  after	Xnest 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 Xnest to inherit the keyboard and	pointer	con-
  trol parameters from the real	server rather than imposing its	own.  This is
  a future consideration.

XNEST AS A SERVER

  Xnest	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.

  As already mentioned,	Xnest is a very	user friendly server when it comes to
  customization.  Xnest	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, Xnest should read a customization input file to provide even
  greater freedom and simplicity in selecting the desired layout.  Unfor-
  tunately, there is no	support	for backing store and save under as of yet,
  but this should also be considered in	the future development of Xnest.

  The only apparent intricacy from the users' perspective about	using Xnest
  as a server is the selection of fonts.  Xnest	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
  os 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	Xnest 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.  Xlsfonts	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	suc-
  cessfully 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.

BUGS

  Won't	run well on servers supporting different visual	depths.	Still crashes
  randomly.  Probably has some memory leaks.

AUTHOR

  Davor	Matic, MIT X Consortium