• Last 5 Forum Topics
    Last post

The Web Only This Site



  • MARC

    Mailing list ARChives
    - Search by -


    Computing Dictionary

  • Text Link Ads

  • LINUX man pages
  • Linux Man Page Viewer

    The following form allows you to view linux man pages.





           Xnest [ options ]


           Xnest  is  both  an X client and an X 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 graph-
           ics requests on their behalf.  To these clients, Xnest appears to be  a
           conventional server.


           Xnest  supports  all  standard options of the sample server implementa-
           tion.  For more details, please see Xserver(1).   The  following  addi-
           tional arguments are supported as well.
           -display string
                  This  option  specifies the display name of the real server that
                  Xnest should try to connect to.  If it is not  provided  on  the
                  command  line,  Xnest will read the DISPLAY environment variable
                  in order to find out this information.
           -sync  This option tells Xnest to synchronize its window  and  graphics
                  operations  with  the  real server.  This is a useful option for
                  debugging, but it will slow down Xnest's  performance  consider-
                  ably.  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 regenerates 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 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 genera-
           -class string
                  This option specifies the default visual  class  of  the  nested
                  server.   It  is similar to the -cc option from the set of stan-
                  dard 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,  Static-
                  Color,  PseudoColor,  TrueColor,  or  DirectColor.   If both the
                  -class and -cc options  are  specified,  the  last  instance  of
                  either option takes 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, but it must be supported by
                  the real server.  Use xdpyinfo(1) to obtain 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 color
                  map  will be preallocated.  If the user chooses a dynamic class,
                  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 WxH+X+Y
                  This  option specifies the geometry parameters for the top-level
                  Xnest window.  See "GEOMETRY SPECIFICATIONS" in X(7) for a  dis-
                  cusson  of this option's syntax.  This window corresponds to the
                  root window of the nested server.  The  width  W  and  height  H
                  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.   Xnest  does
                  not  yet support the RANDR extension for resizing, rotation, and
                  reflection of the root window.  If this option is not specified,
                  Xnest  will  choose  W  and H to be 3/4ths 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  int  must  be  positive.  The
                  default border width is 1.
           -name string
                  This option specifies the name of the top-level Xnest window  as
                  string.  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 window.  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(1) 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.
                  This option tells Xnest to do its own color map installation  by
                  bypassing the real window manager.  For it to work properly, the
                  user will probably have to temporarily quit the real window man-
                  ager.   By  default,  Xnest  will  keep the nested client window
                  whose color map should be installed in the real  server  in  the
                  WM_COLORMAP_WINDOWS  property of the top-level Xnest window.  If
                  this color map 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_COL-
                  ORMAP_WINDOWS property rather than the color map associated with
                  the  top-level Xnest window.  Unfortunately, window managers are
                  not very good at doing that yet so this  option  might  come  in
           ning 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 process  in  the  first  nested  server  and
           'xterm  -display  :2'  will  start an xterm in the second nested server
           from the example above.  Additional clients can be started  from  these
           xterms in each nested server.
       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.   There-
           fore,  it  is  desirable  that Xnest and the real server are on a local
           network, or even better, on the same machine.  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, in which case the real server need not support it.
           Dynamic SHAPE extension selection support may be considered in  further
           development of Xnest.
           Since  Xnest  need  not  use  the  same  default visual as the the real
           server, the top-level window of the Xnest client  always  has  its  own
           color  map.   This  implies that other windows' colors will not be dis-
           played properly while the keyboard or pointer focus  is  in  the  Xnest
           window,  unless the real server has support for more than one installed
           color map at any time.  The color map associated with the top window of
           the  Xnest client need not be the appropriate color map that the nested
           server wants installed in the real server.  In the case that  a  nested
           client  attempts  to install a color map 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 color map into the  WM_COLORMAP_WINDOWS  property  of  the
           top-level  Xnest window on the real server.  Thus, it is important that
           the real window manager that manages the Xnest top-level  window  looks
           at  the  WM_COLORMAP_WINDOWS property rather than the color map associ-
           ated with the top-level Xnest window.  Since most window managers don't
           yet  appear to implement this convention properly, Xnest can optionally
           do direct installation of color maps 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 color map 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 con-
           trols of the real server to its own internal defaults.
       Xnest as a server
           operation, although it is  really  a  bug.   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.  The xlsfonts(1) 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.


           Make  dynamic  the  requirement  for  the  SHAPE  extension in the real
           server, rather than having to recompile Xnest to turn this  requirement
           on and off.
           Perhaps  there should be a command-line option to tell Xnest to inherit
           the keyboard and pointer control parameters from the real server rather
           than imposing its own.
           Xnest  should  read  a customization input file to provide even greater
           freedom and simplicity in selecting the desired layout.
           There is no support for backing store and save unders, but this  should
           also be considered.
           The proper implementation of fonts should be moved into the os layer.


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


           Davor Matic, MIT X Consortium


           Xserver(1), xdpyinfo(1), X(7)

    X Version 11 xorg-server 1.11.3 Xnest(1)


  • Linux

    The Distributions


    The Software


    The News


  • Toll Free
Copyright © 1999 - 2016 by LinuxGuruz