git update until 25 Mar 2011

xserver 
fontconfig
glproto
libXau
libXft
libXmu
libfontenc
libxcb
mesa
mkfontscale
pixman
randrproto
xkeyboard-config
xtrans
xwininfo

updated following packages:

xproto-7.0.21
xineramaproto-1.2.1
libXt-1.1.1
libxkbfile-1.0.7
libXpm-3.5.9
libXfont-1.4.3
libXaw-1.0.9
bdftopcf-1.0.3
encodings-1.0.4
fixesproto-5.0
font-adobe-100dpi-1.0.3
font-adobe-75dpi-1.0.3
font-adobe-utopia-100dpi-1.0.4
font-adobe-utopia-75dpi-1.0.4
font-adobe-utopia-type1-1.0.4
font-alias-1.0.3
font-arabic-misc-1.0.3
font-bh-100dpi-1.0.3
font-bh-75dpi-1.0.3
font-bh-lucidatypewriter-100dpi-1.0.3
font-bh-lucidatypewriter-75dpi-1.0.3
font-bh-ttf-1.0.3
font-bh-type1-1.0.3
font-bitstream-100dpi-1.0.3
font-bitstream-75dpi-1.0.3
font-bitstream-speedo-1.0.2
font-bitstream-type1-1.0.3
font-cronyx-cyrillic-1.0.3
font-cursor-misc-1.0.3
font-daewoo-misc-1.0.3
font-dec-misc-1.0.3
font-ibm-type1-1.0.3
font-isas-misc-1.0.3
font-jis-misc-1.0.3
font-micro-misc-1.0.3
font-misc-cyrillic-1.0.3
font-misc-ethiopic-1.0.3
font-misc-meltho-1.0.3
font-misc-misc-1.1.2
font-mutt-misc-1.0.3
font-schumacher-misc-1.1.2
font-screen-cyrillic-1.0.4
font-sony-misc-1.0.3
font-sun-misc-1.0.3
font-util-1.2.0
font-winitzki-cyrillic-1.0.3
font-xfree86-type1-1.0.4

1 files changed, 0 insertions, 84 deletions

diff --git a/libXaw/spec/CH6.intro b/libXaw/spec/CH6.intro
deleted file mode 100644
index 530f2f7f9..000000000
--- a/libXaw/spec/CH6.intro
+++ /dev/null
@@ -1,84 +0,0 @@
-.LP
-.bp
-.if e .bp  \" make sure we break on an odd page.
-\&
-.sp 1
-.ce 3
-\s+1\fBChapter 6\fP\s-1
-
-\s+1\fBComposite and Constraint Widgets\fP\s-1
-.sp 2
-.nr H1 6
-.nr H2 0
-.nr H3 0
-.nr H4 0
-.nr H5 0
-.na
-.LP
-.XS
-Chapter 6 - Composite and Constraint Widgets
-.XE
-.LP
-These widgets may contain arbitrary widget children.  They implement a
-policy for the size and location of their children.
-.IP \fBBox\fP 1i
-.IN "Box widget" ""
-This widget will pack its children as tightly as possible in
-non-overlapping rows.
-.IP \fBDialog\fP 1i
-.IN "Dialog widget" ""
-An implementation of a commonly used interaction semantic to prompt for
-auxiliary input from the user, such as a filename.
-.IP \fBForm\fP 1i
-.IN "Form widget" ""
-A more sophisticated layout widget that allows the children to specify
-their positions relative to the other children, or to the edges of the Form.
-.IP \fBPaned\fP 1i
-.IN "Paned widget" ""
-Allows children to be tiled vertically or horizontally.  Controls are
-also provided to allow the user to dynamically resize the individual panes.
-.IP \fBPorthole\fP 1i
-.IN "Porthole widget" ""
-Allows viewing of a managed child which is as large as, or larger than its
-parent, typically under control of a Panner widget.
-.IP \fBTree\fP 1i
-.IN "Tree widget" ""
-Provides geometry management of widgets arranged in a directed, acyclic graph.
-.IP \fBViewport\fP 1i
-.IN "Viewport widget" ""
-Consists of a frame, one or two scrollbars, and an inner window.  The
-inner window can contain all the data that is to be displayed.  This inner
-window will be clipped by the frame with the scrollbars controlling
-which section of the inner window is currently visible.
-.LP
-.NH 3
-A Brief Note on Geometry Management
-.IN "geometry management" ""
-.LP
-The geometry management semantics provided by the X Toolkit give full
-control of the size and position of a widget to the parent of that
-widget.  While the children are allowed to request a certain size or
-location, it is the parent who makes the final decision.  Many of the
-composite widgets here will deny any geometry request from their
-children by default.  If a child widget is not getting the expected size
-or location, it is most likely the parent disallowing a request, or
-implementing semantics slightly different than those expected by the
-application programmer.
-.LP
-If the application wishes to change the size or location of
-any widget it should make a call to \fBXtSetValues\fP.  This will
-.IN "XtSetValues" ""
-allow the widget to ask its parent for the new size or location.
-As noted above the parent is allowed to refuse this request,
-and the child must live with the result.  If the
-application is unable to achieve the desired semantics, then perhaps it
-should use a different composite widget.  Under no circumstances
-should an application programmer resort to \fBXtMoveWidget\fP or
-.IN "XtMoveWidget" ""
-\fBXtResizeWidget\fP; these functions are exclusively for the use of
-.IN "XtResizeWidget" ""
-Composite widget implementors.
-.LP
-For more information on geometry management consult the \fI\*(xT\fP.
-
-