Nested structs which are generated for named case and bitcase do not get a typename anymore, i.e., they are anonymous structs. Reasons for this change: * Prior typenames have caused nameclashes * Prior typenames introduced names in the global namespace which did not start with the xcb prefix. This change is safe with respect to API compatibility because: I have searched for instances of named bitcases and there's only one place where they are used, and that's in xkb.xml: reply GetKbdByName. ( no need to search for <case> because it was introduced after the last release ) The reply GetKbdByName is broken in its current form in the xkb.xml anyways, so it is most probably not used anywhere. So, my conclusion is that we can safely omit named types for nested structs. No need for an attribute. Message-ID: <1409731849-51897-1-git-send-email-chris@demorecorder.com> Patch-Thread-Subject: Re: [Xcb] names of nested structs of named bitcase/case are prone to nameclashes. Solution? Patch-Set: NestedStructTypenames Patch-Number: libxcb 1/1 Patch-Version: V1 Signed-off-by: Christian Linhart <chris@DemoRecorder.com> Reviewed-By: Ran Benita <ran234@gmail.com> |
||
---|---|---|
doc | ||
m4 | ||
man | ||
src | ||
tests | ||
tools | ||
.autom4te.cfg | ||
.gitignore | ||
COPYING | ||
Makefile.am | ||
NEWS | ||
README | ||
autogen.sh | ||
check-pc-requires | ||
configure.ac | ||
xcb-composite.pc.in | ||
xcb-damage.pc.in | ||
xcb-dpms.pc.in | ||
xcb-dri2.pc.in | ||
xcb-dri3.pc.in | ||
xcb-glx.pc.in | ||
xcb-present.pc.in | ||
xcb-randr.pc.in | ||
xcb-record.pc.in | ||
xcb-render.pc.in | ||
xcb-res.pc.in | ||
xcb-screensaver.pc.in | ||
xcb-shape.pc.in | ||
xcb-shm.pc.in | ||
xcb-sync.pc.in | ||
xcb-xevie.pc.in | ||
xcb-xf86dri.pc.in | ||
xcb-xfixes.pc.in | ||
xcb-xinerama.pc.in | ||
xcb-xinput.pc.in | ||
xcb-xkb.pc.in | ||
xcb-xprint.pc.in | ||
xcb-xselinux.pc.in | ||
xcb-xtest.pc.in | ||
xcb-xv.pc.in | ||
xcb-xvmc.pc.in | ||
xcb.pc.in |
About libxcb ============ libxcb provides an interface to the X Window System protocol, which replaces the current Xlib interface. It has several advantages over Xlib, including: - size: small, simple library, and lower memory footprint - latency hiding: batch several requests and wait for the replies later - direct protocol access: interface and protocol correspond exactly - 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. 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/libxcb For developers, use: git clone git+ssh://git.freedesktop.org/git/xcb/libxcb