[Xcb-commit] 2 commits - NEWS README configure.ac src
Jamey Sharp
jamey at kemper.freedesktop.org
Sat Oct 7 19:46:38 PDT 2006
NEWS | 48 +++++++++++++++++++++++++++++++++
README | 34 ++++++++++++++++++++++++
configure.ac | 2 -
src/extensions/render.xml | 65 ++--------------------------------------------
4 files changed, 86 insertions(+), 63 deletions(-)
New commits:
diff-tree 4b738b87b2e3791877e9e0d6ba66f48282f174f7 (from 4e5e08b3251fe9174ae94e01ce3b682b0ffa9967)
Author: Jamey Sharp <jamey at minilop.net>
Date: Sat Oct 7 19:46:15 2006 -0700
Release xcb-proto 1.0 RC2 (0.9.92).
diff --git a/NEWS b/NEWS
new file mode 100644
index 0000000..dd18f3d
--- /dev/null
+++ b/NEWS
@@ -0,0 +1,48 @@
+Release 1.0 RC2 (2006-10-07)
+============================
+
+* Add <import>xproto</import> explicitly to extensions that use xproto;
+ this goes along with the change in the code generator for libxcb 1.0 RC2 to
+ stop implicitly importing xproto.
+* Change "union" to "xidunion" for XID unions like DRAWABLE and FONTABLE,
+ so that the code generator can more easily declare these XID unions as
+ integer typedefs rather than unions.
+* Replace structures attempting to provide C type safety with CARD32 typedefs
+* render.xml no longer describes the CompositeGlyphs* requests as taking lists
+ of complicated unions of structures of lists: it says instead that they take
+ a LISTofBYTE. The caller is responsible for constructing an appropriate
+ sequence of glyph elements. Previously, the requests could not actually be
+ used because XCB did not correctly compute the length of the provided data.
+
+
+Release 1.0 RC1 (2006-09-25)
+============================
+
+The Great XCB Renaming
+----------------------
+
+* Rename shape_op and shape_kind to drop the "shape_" prefix, since
+ otherwise these types end up as xcb_shape_shape_{op,kind}_t.
+* Remove leading underscores from enums in the GLX protocol description,
+ previously needed to ensure a word separator, but now redundant.
+* The XML-XCB protocol descriptions have moved to /usr/share/xcb, with
+ extension descriptions no longer relegated to an extensions/ subdirectory.
+
+GIT Repository split
+--------------------
+
+Previously, several XCB-related projects all existed under the umbrella
+of a single monolithic GIT repository with per-project subdirectories.
+We have split this repository into individual per-project repositories.
+
+Josh Triplett and Jamey Sharp wrote a tool called git-split to
+accomplish this repository split. git-split reconstructs the history of
+a sub-project previously stored in a subdirectory of a larger
+repository. It constructs new commit objects based on the existing tree
+objects for the subtree in each commit, and discards commits which do
+not affect the history of the sub-project, as well as merges made
+unnecessary due to these discarded commits.
+
+We would like to acknowledge the work of the gobby team in creating a
+collaborative editor which greatly aided the development of git-split
+(as well as these release notes).
diff --git a/README b/README
new file mode 100644
index 0000000..3c24331
--- /dev/null
+++ b/README
@@ -0,0 +1,34 @@
+About xcb-proto
+===============
+
+xcb-proto provides the XML-XCB protocol descriptions that libxcb uses to
+generate the majority of its code and API. We provide them separately
+from libxcb to allow reuse by other projects, such as additional
+language bindings, protocol dissectors, or documentation generators.
+
+This separation between the XCB transport layer and the
+automatically-generated protocol layer also makes it far easier to write
+new extensions. With the Xlib infrastructure, client-side support for
+new extensions requires significant duplication of effort. With XCB and
+the XML-XCB protocol descriptions, client-side support for a new
+extension requires only an XML description of the extension, and not a
+single line of code.
+
+Please report any issues you find to the freedesktop.org bug tracker,
+at:
+
+ <https://bugs.freedesktop.org/enter_bug.cgi?product=XCB>
+
+Discussion about XCB occurs on the XCB mailing list:
+
+ <mailto:xcb at lists.freedesktop.org>
+ <http://lists.freedesktop.org/mailman/listinfo/xcb>
+
+You can obtain the latest development versions of XCB using GIT.
+For anonymous checkouts, use:
+
+ git clone git://anongit.freedesktop.org/git/xcb/proto
+
+For developers, use:
+
+ git clone git+ssh://git.freedesktop.org/git/xcb/proto
diff --git a/configure.ac b/configure.ac
index cc1dfd7..9d51d75 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,7 +3,7 @@
AC_PREREQ(2.57)
AC_INIT([XCB Proto],
- 0.9.91,
+ 0.9.92,
[xcb at lists.freedesktop.org])
AC_CONFIG_SRCDIR([xcb-proto.pc.in])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
diff-tree 4e5e08b3251fe9174ae94e01ce3b682b0ffa9967 (from b8071b0fa537a759be69892508ea8b9427b2adb1)
Author: Jamey Sharp <jamey at minilop.net>
Date: Sat Oct 7 19:37:54 2006 -0700
Make CompositeGlyphs* usable.
render.xml no longer describes the CompositeGlyphs* requests as taking
lists of complicated unions of structures of lists: it says instead that
they take a LISTofBYTE. The caller is responsible for constructing an
appropriate sequence of glyph elements. Previously, the requests could
not actually be used because XCB did not correctly compute the length of
the provided data.
diff --git a/src/extensions/render.xml b/src/extensions/render.xml
index a59f7e7..7dbf926 100644
--- a/src/extensions/render.xml
+++ b/src/extensions/render.xml
@@ -373,31 +373,6 @@ for licensing information.
<list type="GLYPH" name="glyphs" />
</request>
- <struct name="GLYPHSETELT">
- <field type="CARD8" name="len" />
- <pad bytes="3" />
- <field type="INT16" name="deltax" />
- <field type="INT16" name="deltay" />
- <field type="GLYPHSET" name="glyphset" />
- </struct>
-
- <!-- CompositeGlyphs8 -->
-
- <struct name="GLYPHELT8">
- <field type="CARD8" name="len" />
- <pad bytes="3" />
- <field type="INT16" name="deltax" />
- <field type="INT16" name="deltay" />
- <list type="CARD8" name="glyphs">
- <fieldref>len</fieldref>
- </list>
- </struct>
-
- <union name="GLYPHITEM8">
- <field type="GLYPHELT8" name="glyphelt" />
- <field type="GLYPHSETELT" name="glyphset" />
- </union>
-
<request name="CompositeGlyphs8" opcode="23">
<field type="CARD8" name="op" />
<pad bytes="3" />
@@ -407,26 +382,9 @@ for licensing information.
<field type="GLYPHSET" name="glyphset" />
<field type="INT16" name="src_x" />
<field type="INT16" name="src_y" />
- <list type="GLYPHITEM8" name="glyphcmds" />
+ <list type="BYTE" name="glyphcmds" />
</request>
- <!-- CompositeGlyphs16 -->
-
- <struct name="GLYPHELT16">
- <field type="CARD8" name="len" />
- <pad bytes="3" />
- <field type="INT16" name="deltax" />
- <field type="INT16" name="deltay" />
- <list type="CARD16" name="glyphs">
- <fieldref>len</fieldref>
- </list>
- </struct>
-
- <union name="GLYPHITEM16">
- <field type="GLYPHELT16" name="glyphelt" />
- <field type="GLYPHSETELT" name="glyphset" />
- </union>
-
<request name="CompositeGlyphs16" opcode="24">
<field type="CARD8" name="op" />
<pad bytes="3" />
@@ -436,26 +394,9 @@ for licensing information.
<field type="GLYPHSET" name="glyphset" />
<field type="INT16" name="src_x" />
<field type="INT16" name="src_y" />
- <list type="GLYPHITEM16" name="glyphcmds" />
+ <list type="BYTE" name="glyphcmds" />
</request>
- <!-- CompositeGlyphs32 -->
-
- <struct name="GLYPHELT32">
- <field type="CARD8" name="len" />
- <pad bytes="3" />
- <field type="INT16" name="deltax" />
- <field type="INT16" name="deltay" />
- <list type="CARD32" name="glyphs">
- <fieldref>len</fieldref>
- </list>
- </struct>
-
- <union name="GLYPHITEM32">
- <field type="GLYPHELT32" name="glyphelt" />
- <field type="GLYPHSETELT" name="glyphset" />
- </union>
-
<request name="CompositeGlyphs32" opcode="25">
<field type="CARD8" name="op" />
<pad bytes="3" />
@@ -465,7 +406,7 @@ for licensing information.
<field type="GLYPHSET" name="glyphset" />
<field type="INT16" name="src_x" />
<field type="INT16" name="src_y" />
- <list type="GLYPHITEM32" name="glyphcmds" />
+ <list type="BYTE" name="glyphcmds" />
</request>
<!-- new in version 0.1 -->
More information about the xcb-commit
mailing list