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.
This commit is contained in:
2018-09-08 19:39:28 +02:00
parent 3173202cc1
commit 48fb710f35
14 changed files with 111 additions and 136 deletions

View File

@@ -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