NAME

Xnest - a nested X server

SYNOPSIS

Xnest [-options]

DESCRIPTION

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

OPTIONS

_X_n_e_s_t supports all standard options of the sample server implementation. For more details, please see the manual page on your system for _X_s_e_r_v_e_r. The following additional arguments are supported as well.
-display _s_t_r_i_n_g
This option specifies the display name of the real server that _X_n_e_s_t should try to connect with. If it is not provided on the command line _X_n_e_s_t will read the _D_I_S_P_L_A_Y environment variable in order to find out the same information.
-sync
This option tells _X_n_e_s_t 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.
-full
This option tells _X_n_e_s_t 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, _X_n_e_s_t 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.
-class _s_t_r_i_n_g
This option specifies the default visual class of the nested server. It is similar to the _-_c_c 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: _S_t_a_t_i_c_G_r_a_y, _G_r_a_y_S_c_a_l_e, _S_t_a_t_i_c_C_o_l_o_r, _P_s_e_u_d_o_C_o_l_o_r, _T_r_u_e_C_o_l_o_r, or _D_i_r_e_c_t_C_o_l_o_r. If both, _-_c_l_a_s_s and _-_c_c 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 _x_d_p_y_i_n_f_o for a list of supported visual classes on the real server before starting _X_n_e_s_t. 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.
-depth _i_n_t
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 _x_d_p_y_i_n_f_o for a list of supported visual depths on the real server before starting _X_n_e_s_t.
-sss
This option tells _X_n_e_s_t to use the software screen saver. By default _X_n_e_s_t 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 _X_n_e_s_t does not control any actual hardware. However, it is treated as a hardware screen saver within the sample server code.
-geometry _W_x_H_+_X_+_Y
This option specifies geometry parameters for the top level _X_n_e_s_t 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 _X_n_e_s_t window. _X_n_e_s_t 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 _X_n_e_s_t will choose width and height to be 3/4 of the dimensions of the root window of the real server.
-bw _i_n_t
This option specifies the border width of the top level _X_n_e_s_t window. The integer parameter must be a positive number. The default border width is 1.
-name _s_t_r_i_n_g
This option specifies the name of the top level _X_n_e_s_t window. The default value is the program name.
-scrns _i_n_t
This option specifies the number of screens to create in the nested server. For each screen, _X_n_e_s_t 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, _x_t_e_r_m _-_d_i_s_p_l_a_y _:_1_._1 will open an _x_t_e_r_m 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 _X_n_e_s_t 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 _X_n_e_s_t will keep the nested client window whose colormap should be installed in the real server in the _W_M___C_O_L_O_R_M_A_P___W_I_N_D_O_W_S property of the top level _X_n_e_s_t window. If this colormap is of the same visual type as the root window of the nested server, _X_n_e_s_t will associate this colormap with the top level _X_n_e_s_t window as well. Since this does not have to be the case, window managers should look primarily at the _W_M___C_O_L_O_R_M_A_P___W_I_N_D_O_W_S property rather than the colormap associated with the top level _X_n_e_s_t window. Unfortunately, window managers are not very good at doing that yet so this option might come in handy.
-parent _w_i_n_d_o_w___i_d
This option tells _X_n_e_s_t to use the _w_i_n_d_o_w___i_d as the root window instead of creating a window. This option is used by the xrx xnestplugin.

USAGE

Starting up _X_n_e_s_t is as simple as starting up _x_c_l_o_c_k from a terminal emulator. If a user wishes to run _X_n_e_s_t 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, _X_n_e_s_t 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 _X_n_e_s_t _:_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 _X_n_e_s_t, you will need to type _X_n_e_s_t _:_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, _x_t_e_r_m _-_d_i_s_p_l_a_y _:_1 will start up an _x_t_e_r_m in the first nested server and _x_t_e_r_m _-_d_i_s_p_l_a_y _:_2 will start an _x_t_e_r_m in the second nested server from the example above. Additional clients can be started from these _x_t_e_r_ms in each nested server.

XNEST AS A CLIENT

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

Since _X_n_e_s_t need not use the same default visual as the the real server, the top level window of the _X_n_e_s_t 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 _X_n_e_s_t 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 _X_n_e_s_t 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, _X_n_e_s_t 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 _W_M___C_O_L_O_R_M_A_P___W_I_N_D_O_W_S property of the top level _X_n_e_s_t window on the real server. Thus, it is important that the real window manager that manages the _X_n_e_s_t top level window looks at the _W_M___C_O_L_O_R_M_A_P___W_I_N_D_O_W_S property rather than the colormap associated with the top level _X_n_e_s_t window. Since most window managers appear to not implement this convention properly as of yet, _X_n_e_s_t 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 _X_n_e_s_t 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 _X_n_e_s_t 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 _X_n_e_s_t to inherit the keyboard and pointer control parameters from the real server rather than imposing its own. This is a future consideration.

XNEST AS A SERVER

_X_n_e_s_t 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, _X_n_e_s_t is a very user friendly server when it comes to customization. _X_n_e_s_t 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, _X_n_e_s_t 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 _X_n_e_s_t.

The only apparent intricacy from the users' perspective about using _X_n_e_s_t as a server is the selection of fonts. _X_n_e_s_t 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 _o_s 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 _X_n_e_s_t 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. _X_l_s_f_o_n_t_s 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.

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