[Xcb] [ANNOUNCE] XCB 1.0 release candidate 1 now available
Barton C Massey
bart at cs.pdx.edu
Tue Sep 26 00:40:43 PDT 2006
Big congratulations to all of you who have contributed over
the past 5+ years to reach this point, and big
congratulations to the team that has scrambled for the last
few weeks to get a release out the door. Your efforts are
hugely valued.
Bart Massey
Assoc. Prof. Computer Science
Portland State University
bart at cs.pdx.edu
In message <20060926061729.GA15591 at id.minilop.net> you wrote:
>
> --===============0359451758==
> Content-Type: multipart/signed; micalg=pgp-sha1;
> protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0"
> Content-Disposition: inline
>
>
> --k+w/mQv8wyuph6w0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> The XCB developers proudly announce the 1.0 RC1 (0.9.91) release of
> xcb-proto and libxcb, now available from:
>
> <http://xcb.freedesktop.org/dist/xcb-proto-0.9.91.tar.bz2>
> with sha1sum: b447894b8e46bc36dec89cf0ccd65e2db5e20b94
>
> <http://xcb.freedesktop.org/dist/xcb-proto-0.9.91.tar.gz>
> with sha1sum: b05f6f14d9266aa3827a444a2d77c453c1b3131d
>
> <http://xcb.freedesktop.org/dist/libxcb-0.9.91.tar.bz2>
> with sha1sum: 8da28b68107613b67dc0dc51dc06a361b11953b4
>
> <http://xcb.freedesktop.org/dist/libxcb-0.9.91.tar.gz>
> with sha1sum: edad8cb60daad429bc8ef0635ab2d6aeb6b6ae5d
>
> About libxcb
> ------------
>
> libxcb provides an interface to the X Window System protocol, slated to
> replace the current Xlib interface. It has several advantages over
> Xlib, including:
> - size: small library and lower memory footprint
> - latency hiding: batch several requests and wait for the replies later
> - direct protocol access: one-to-one mapping between interface and protocol
> - proven thread support: transparently access XCB from multiple threads
> - easy extension implementation: interfaces auto-generated from XML-XCB
>
> Xlib can also use XCB as a transport layer, allowing software to make
> requests and receive responses with both, which eases porting to XCB.
> However, client programs, libraries, and toolkits will gain the most
> benefit from a native XCB port.
>
> 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
> =66rom 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.
>
> Why this release?
> -----------------
>
> We have provided this candidate release to allow for more widespread
> review and testing before XCB 1.0. As of version 1.0, libxcb will
> provide a stable API and ABI; future changes will consist only of
> additions, and applications compiled against XCB 1.0 or newer will work
> with all future versions of XCB. Barring discovery of serious issues
> with the API, we do not anticipate any API changes between this release
> and the 1.0 release.
>
> We would greatly appreciate API review in this final release candidate
> period. We've had some limited feedback that our attempts to impose
> static type safety on XIDs in C pose more a hindrance than a help, so we
> would appreciate discussion over whether this constitutes a "serious
> issue with the API". Some question also remains of whether
> xcb_poll_for_event should have the out-parameter 'error', now that XCB
> has a more uniform mechanism for reporting connection errors. Speak now
> on these points or leave us alone. ;-)
>
> XCB has received testing on various operating systems, including
> GNU/Linux (multiple distributions), FreeBSD, Solaris, and MacOS X. Most
> testing has occurred on x86 and x86-64, but big-endian processors such
> as PowerPC and SPARC have also received limited testing. The library
> should build with recent versions of GCC and Sun's compiler. We would
> welcome testing on more diverse operating systems, processors, and
> compilers.
>
> Please report any issues you find to the freedesktop.org bug tracker,
> at:
>
> <https://bugs.freedesktop.org/enter_bug.cgi?product=3DXCB>
>
> 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. We have
> split the previous monolithic GIT repository into separate repositories
> for each project; for details on this split and the tool created to do
> it, see the release notes below. For anonymous checkouts, use:
>
> git clone git://anongit.freedesktop.org/git/xcb/libxcb
> git clone git://anongit.freedesktop.org/git/xcb/proto
>
> For developers, use:
>
> git clone git+ssh://git.freedesktop.org/git/xcb/libxcb
> git clone git+ssh://git.freedesktop.org/git/xcb/proto
>
> This release corresponds to the GIT tag "1.0-RC1", signed by Jamey Sharp
> with key ID 0E08F665. In each repository, the tag may be verified with
> the command:
>
> git verify-tag 1.0-RC1
>
> Detailed notes on this release follow.
>
> -- Jamey Sharp <jamey at minilop.net>, Josh Triplett <josh at freedesktop.org>
>
> Release 1.0 RC1 (2006-09-25)
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D
>
> The Great XCB Renaming
> ----------------------
>
> Rename API to follow a new naming convention:
>
> * XCB_CONSTANTS_UPPERCASE_WITH_UNDERSCORES
> * xcb_functions_lowercase_with_underscores
> * xcb_types_lowercase_with_underscores_and_suffix_t
> * expand all abbreviations like "req", "rep", and "iter"
>
> Word boundaries for the names in the protocol descriptions fall:
>
> * Wherever the protocol descriptions already have an underscore
> * Between a lowercase letter and a subsequent uppercase letter
> * Before the last uppercase letter in a string of uppercase letters
> followed by a lowercase letter (such as in LSBFirst between LSB and
> First)
> * Before and after a string of digits (with exceptions for sized types
> like xcb_char2b_t and xcb_glx_float32_t to match the stdint.h
> convention)
>
> Also fix up some particular naming issues:
>
> * 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.
>
> This renaming breaks code written for the previous API naming
> convention. The scripts in XCB's tools directory will convert code
> written for the old API to use the new API; they work well enough that
> we used them to convert the non-program-generated code in XCB, and when
> run on the old program-generated code, they almost exactly reproduce the
> new program-generated code (modulo whitespace and bugs in the old code
> generator).
>
> Authors: Vincent Torri, Thomas Hunger, Josh Triplett
>
> In addition to the API renaming, the library SONAMEs have changed to
> libxcb.so and libxcb-extname.so. The library major version remains at 0,
> to become version 1 before 1.0 is released; the SONAME lowercasing means
> that this will not conflict with XCB 0.9 libraries.
>
> The header files have moved from /usr/include/X11/XCB/ to
> /usr/include/xcb/. The XML-XCB protocol descriptions have moved to
> /usr/share/xcb, with extension descriptions no longer relegated to an
> extensions/ subdirectory. The API conversion script api_conv.pl will fix
> references to the header files, and packages using pkg-config will
> automatically use the new library names.
>
> Error handling Plan 7
> ---------------------
>
> All request functions now come in an "unchecked" and "checked" variant.
> The checked variant allows callers to handle errors inline where they
> obtain the reply, or by calling xcb_request_check for requests with no
> reply. The unchecked variant uses the event queue for errors. Requests
> with replies default to checked, because the caller must already make a
> function call to retrieve the reply and can see the error at that time;
> the unchecked variant uses the suffix _unchecked. Requests without
> replies default to unchecked, because the caller will not necessarily
> expect to handle a response, and the checked variant uses the suffix
> _checked.
>
> Connection error handling
> -------------------------
>
> Fatal connection errors now put the xcb_connection_t object into an
> error state, at which point all further operations on that connection
> will fail. Callers can use the new xcb_connection_has_error function to
> check for this state in a connection. Functions that return a
> connection, such as the xcb_connect function, may instead return an
> xcb_connection_t already in an error state.
>
> In the future we expect to add additional API for getting more
> information about the error condition that caused the connection to get
> into an error state.
>
> Smaller API changes
> -------------------
>
> All functions that have been marked 'deprecated' up to now have been
> removed for this release. After XCB 1.0 is released, functions marked
> 'deprecated' will be preserved until the end of time to maintain
> compatibility.
>
> XCB no longer provides a sync function. Most callers of this function
> should use xcb_flush instead, which usually provides the intended
> functionality and does not require a round-trip to the server. If you
> really need this functionality, either use xcb_get_input_focus like sync
> used to do, or use the xcb_aux_sync function from the xcb-aux library in
> xcb-util. However, note that we do not consider the libraries in
> xcb-util remotely stable yet.
>
> XCB no longer provides xcb_[extension_name]_init functions for each
> extension. These functions previously caused XCB to issue and process a
> QueryExtension request. Callers should now directly call
> xcb_get_extension_data on the xcb_[extension_name]_id, or use
> xcb_prefetch_extension_data if they do not need to force a round-trip
> immediately.
>
> The compatibility functions in xcbxlib.h, provided solely for use by
> Xlib/XCB, now exist in a separate library libxcb-xlib. We don't want to
> have to change the libxcb soname if we later change or remove the Xlib
> compatibility functions, and nothing except Xlib/XCB should ever use
> them. (Applications which use Xlib/XCB do not need this library either;
> Xlib/XCB only uses it internally.)
>
> The descriptions of several extensions have been updated to match the
> latest versions implemented in the X.org X server.
>
> 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).
>
> Build and implementation fixes
> ------------------------------
>
> XCB no longer needs proto/x11 from X.org; the XCB header xproto.h
> provides the definitions from X.h, named according to XCB conventions.
>
> XCB should now build with non-GNU implementations of Make.
>
> XCB properly handles 32-bit wrap of sequence numbers, and thus now
> supports issuing more than 2**32 requests in one connection.
>
> Fixed bugs #7001, #7261.
>
> --k+w/mQv8wyuph6w0
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: Digital signature
> Content-Disposition: inline
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
>
> iD8DBQFFGMX5p1aplQ4I9mURAoWCAJ0U+MHiBMUxQ0g4Hf7QsuFYjoQ8WwCfXwVB
> 9RjcBfHQ663JmAOvvv7meps=
> =/88W
> -----END PGP SIGNATURE-----
>
> --k+w/mQv8wyuph6w0--
>
> --===============0359451758==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Xcb mailing list
> Xcb at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xcb
> --===============0359451758==--
More information about the Xcb
mailing list