diff options
Diffstat (limited to 'nexgb/doc.go')
| -rw-r--r-- | nexgb/doc.go | 28 |
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 |