nexgb: post-merge fixups and cleanups

AUTHORS, CONTRIBUTORS: still useful, add people from git log, clean up.

LICENSE: Google doesn't really grant you shit anymore.  The EU doesn't
have software patents either, so it doesn't affect me directly.

README, doc.go: erase mentions of unmaintained xgbutil.

1 files changed, 13 insertions, 15 deletions

diff --git a/nexgb/doc.go b/nexgb/doc.go
index 64540e9..a587d4c 100644
--- a/nexgb/doc.go
+++ b/nexgb/doc.go
@@ -1,16 +1,14 @@
 /*
-Package XGB provides the X Go Binding, which is a low-level API to communicate
+Package nexgb provides the X Go Binding, which is a low-level API to communicate
 with the core X protocol and many of the X extensions.
 
 It is *very* closely modeled on XCB, so that experience with XCB (or xpyb) is
-easily translatable to XGB. That is, it uses the same cookie/reply model
+easily translatable to neXGB. That is, it uses the same cookie/reply model
 and is thread safe. There are otherwise no major differences (in the API).
 
-Most uses of XGB typically fall under the realm of window manager and GUI kit
+Most uses of neXGB typically fall under the realm of window manager and GUI kit
 development, but other applications (like pagers, panels, tilers, etc.) may
-also require XGB. Moreover, it is a near certainty that if you need to work
-with X, xgbutil will be of great use to you as well:
-https://github.com/BurntSushi/xgbutil
+also require neXGB.
 
 Example
 
@@ -106,13 +104,13 @@ can be found in examples/xinerama.
 
 Parallelism
 
-XGB can benefit greatly from parallelism due to its concurrent design. For
+neXGB can benefit greatly from parallelism due to its concurrent design. For
 evidence of this claim, please see the benchmarks in xproto/xproto_test.go.
 
 Tests
 
 xproto/xproto_test.go contains a number of contrived tests that stress
-particular corners of XGB that I presume could be problem areas. Namely:
+particular corners of neXGB that I presume could be problem areas. Namely:
 requests with no replies, requests with replies, checked errors, unchecked
 errors, sequence number wrapping, cookie buffer flushing (i.e., forcing a round
 trip every N requests made that don't have a reply), getting/setting properties
@@ -120,12 +118,12 @@ and creating a window and listening to StructureNotify events.
 
 Code Generator
 
-Both XCB and xpyb use the same Python module (xcbgen) for a code generator. XGB
-(before this fork) used the same code generator as well, but in my attempt to
-add support for more extensions, I found the code generator extremely difficult
-to work with. Therefore, I re-wrote the code generator in Go. It can be found
-in its own sub-package, xgbgen, of xgb. My design of xgbgen includes a rough
-consideration that it could be used for other languages.
+Both XCB and xpyb use the same Python module (xcbgen) for a code generator.
+neXGB (before BurntSushi's fork) used the same code generator as well, but in my
+attempt to add support for more extensions, I found the code generator extremely
+difficult to work with. Therefore, I re-wrote the code generator in Go. It can
+be found in its own sub-package, xgbgen, of xgb. My design of xgbgen includes a
+rough consideration that it could be used for other languages.
 
 What works
 
@@ -143,4 +141,4 @@ compiles, unlike XKB). I don't currently have any intention of getting XKB
 working, due to its complexity and my current mental incapacity to test it.
 
 */
-package xgb
+package nexgb